Scalable DNS

Transcript

1. Масштабируя DNS Артём Гавриченков <ag@qrator.net>
2. DNS in a nutshell • 1983 г.: (int32)*host_str;
3. DNS in a nutshell • 1983 г.: (int32)*host_str; • 1997-2017:
4. DNS in a nutshell • 1983 г.: (int32)*host_str; • 1997-2017: • load balancing • geobalancing
5. DNS in a nutshell • 1983 г.: (int32)*host_str; • 1997-2017: • load balancing • geobalancing • ASN policies
6. DNS in a nutshell • 1983 г.: (int32)*host_str; • 1997-2017: • load balancing • geobalancing • ASN policies • AAAA
7. DNS in a nutshell • 1983 г.: (int32)*host_str; • 1997-2017: • load balancing • geobalancing • ASN policies • AAAA • failover
8. DNS in a nutshell • 1983 г.: (int32)*host_str; • 1997-2017: • load balancing • geobalancing • ASN policies • AAAA • failover • DNSSEC
9. DNS in a nutshell • 1983 г.: (int32)*host_str; • 1997-2017: • load balancing • geobalancing • ASN policies • AAAA • failover • DNSSEC • EDNS0 • DANE
10. DNS in a nutshell • 1983 г.: (int32)*host_str; • 1997-2017: • load balancing • geobalancing • ASN policies • AAAA • failover • DNSSEC • EDNS0 • DANE
11. Варианты работы с DNS • Собственная инфраструктура • Managed-решение
12. Три причины не размещать DNS на своей инфраструктуре
13. DNS benchmarks 2013
14. DNS benchmarks 2013
15. DNS benchmarks 2013
16. DNS benchmarks 2013
17. DNS benchmarks 2013
18. DNS benchmarks: 4 года спустя 2017
21. •HTTP: Apache Nginx •DNS: BIND
22. Три причины не размещать DNS на своей инфраструктуре 1. Отсутствие industry adopted scalable-решения
23. Три причины не размещать DNS на своей инфраструктуре 1. Отсутствие industry adopted scalable-решения Насколько вообще важна scalability в DNS?
24. DNS lookup
25. DNS lookup
26. DNS lookup ximaera@nostromo:~$ sudo tcpdump -qni any tcp > /dev/null tcpdump: verbose output suppressed, use -v or -vv for full protocol listening on any, link-type LINUX_SLL (Linux cooked), capture size ^C 792 packets captured 794 packets received by filter 0 packets dropped by kernel ximaera@nostromo:~$ sudo tcpdump -qni any port 53 > /dev/null tcpdump: verbose output suppressed, use -v or -vv for full protocol listening on any, link-type LINUX_SLL (Linux cooked), capture size ^C 104 packets captured 156 packets received by filter 0 packets dropped by kernel ximaera@nostromo:~$
27. DNS 10:00:34.510826 IP (proto UDP (17), length 56) 192.168.1.5.63097 > 8.8.8.8.53: 9508+ A? highload.ru. (29) 10:00:34.588632 IP (proto UDP (17), length 72) 8.8.8.8.53 > 192.168.1.5.63097: 9508 1/0/0 highload.ru. A 178.248.233.16 (47)
28. Однако.
29. Однако. • Вызовы DNS-инфраструктуры: • Latency tasks: геобалансировка
30. Анализ базы MaxMind RIPE Atlas: a platform for Internet measurement. https://atlas.ripe.net/
31. Анализ базы MaxMind RIPE Atlas: a platform for Internet measurement. • MaxMind Country DB accuracy on 7000 Atlas probes, June 2017: 99% • С вероятностью 1/100 MaxMind ошибается при определении страны на точках Atlas • Наше исследование: ошибка достигает 4,6% • Для CityDB, LiteDB результаты куда хуже
32. Анализ базы MaxMind RIPE Atlas: a platform for Internet measurement. • MaxMind Country DB accuracy on 7000 Atlas probes, June 2017: 99% • С вероятностью 1/100 MaxMind ошибается при определении страны на точках Atlas • Наше исследование: ошибка достигает 4,6% • Для CityDB, LiteDB результаты куда хуже • https://stackoverflow.com/questions/22986794/continuously-decreasing- accuracy-of-maxmind-geolite-city • https://www.techdirt.com/articles/20160413/12012834171/how-bad-are- geolocation-tools-really-really-bad.shtml • https://geektimes.ru/post/274108/
33. Анализ базы MaxMind RIPE Atlas: a platform for Internet measurement. • MaxMind Country DB accuracy on 7000 Atlas probes, June 2017: 99% • С вероятностью 1/100 MaxMind ошибается при определении страны на точках Atlas • Наше исследование: ошибка достигает 4,6% • Для CityDB, LiteDB результаты куда хуже • Самое главное: в Интернете нет географии, есть топология
34. Топологическое таргетирование https://ns1.com/solutions/technical-solutions/filter-chain • Filters are like little programs that run inline for every DNS query. • They are attached directly to RFC- compliant DNS records
35. Однако. • Вызовы DNS-инфраструктуры: • Latency tasks: геобалансировка, топологическая балансировка
36. Динамическая конфигурация
37. Динамическая конфигурация Параметры DNS – это уже не статический конфиг, это API в т.ч. для систем управления конфигурациями и приложений: • Provisioning • Stats • Policy management
38. Однако. • Вызовы DNS-инфраструктуры: • Latency tasks: геобалансировка, топологическая балансировка • Динамическая конфигурация: параметры DNS – это уже не статический конфиг, это API в т.ч. для систем управления конфигурациями и приложений • Failover
39. Failover, TTL 120s
40. Однако. • Вызовы DNS-инфраструктуры: • Latency tasks: геобалансировка, топологическая балансировка • Динамическая конфигурация: параметры DNS – это уже не статический конфиг, это API в т.ч. для систем управления конфигурациями и приложений • Failover • Уязвимости и своевременные обновления
41. Однако. • Вызовы DNS-инфраструктуры: • Latency tasks: геобалансировка, топологическая балансировка • Динамическая конфигурация: параметры DNS – это уже не статический конфиг, это API в т.ч. для систем управления конфигурациями и приложений • Failover • Уязвимости и своевременные обновления => требуется поддерживаемое высокопроизводительное решение, своевременно реализующее требуемую функциональность
42. Однако. • Вызовы DNS-инфраструктуры: • Latency tasks: геобалансировка, топологическая балансировка • Динамическая конфигурация: параметры DNS – это уже не статический конфиг, это API в т.ч. для систем управления конфигурациями и приложений • Failover • Уязвимости и своевременные обновления • DDoS-атаки
43. Однако. • Вызовы DNS-инфраструктуры: • Latency tasks: геобалансировка, топологическая балансировка • Динамическая конфигурация: параметры DNS – это уже не статический конфиг, это API в т.ч. для систем управления конфигурациями и приложений • Failover • Уязвимости и своевременные обновления • DDoS-атаки • Требуется anycast • Требуется защита
44. Три причины не размещать DNS на своей инфраструктуре 1. Отсутствие industry adopted scalable-решения 2. Строить самостоятельное решение сложно
45. Как выбрать внешнего поставщика?
46. Как выбрать внешнего поставщика? Даже с anycast’ом – тысячи их! • Dyn • NS1 • Route 53 • Name.com • Azure DNS • Google Cloud DNS • Qrator • Cloudflare
47. Как выбрать внешнего поставщика? Диверсификация!
48. SRTT: Smoothed Round Trip Time
49. “Ящик с усами”
50. SRTT
51. SRTT
52. SRTT
53. Как выбрать внешнего поставщика? • Диверсификация!
54. Как выбрать внешнего поставщика? • Диверсификация! • API!
55. Минутка боли • IETF: организация, занимающаяся утверждением стандартов протоколов (RFC) • Рабочая группа dnsop (DNS operations): 14 активных черновиков RFC
56. Минутка боли • IETF: организация, занимающаяся утверждением стандартов протоколов (RFC) • Рабочая группа dnsop (DNS operations): 14 активных черновиков RFC • IPv6 • Special use domain names and TLDs • Packet capture and wire formats • Terminology and security considerations
57. Минутка боли • IETF: организация, занимающаяся утверждением стандартов протоколов (RFC) • Рабочая группа dnsop (DNS operations): 14 активных черновиков RFC • IPv6 • Special use domain names and TLDs • Packet capture and wire formats • Terminology and security considerations • GeoDNS? No, sorry, it’s not that important!
58. Минутка боли • IETF: организация, занимающаяся утверждением стандартов протоколов (RFC) • GeoDNS? No, sorry, it’s not that important! => GeoDNS реализуется костылями через API managed DNS- сервисов (ну да, и в bind тоже есть)
59. Варианты автоматизации • Zone transfer via AXFR/NOTIFY: стандартный механизм, без Geo и прочих плюшек. Неудобный, поддерживается не всеми провайдерами • Reverse proxy: механизм, стандартный для HTTP, но не для DNS, удобный, вообще почти никем не поддерживается
60. Варианты автоматизации • Zone transfer via AXFR/NOTIFY: стандартный механизм, без Geo и прочих плюшек. Неудобный, поддерживается не всеми провайдерами • Reverse proxy: механизм, стандартный для HTTP, но не для DNS, удобный, вообще почти никем не поддерживается • API managed-сервисов: современные, удобные, у каждого сервиса свои особенные
61. Варианты автоматизации Here comes https://github.com/StackExchange/dnscontrol • Поддерживает целый ряд провайдеров «из коробки» через API • Активно развивается и поддерживается StackExchange
62. CI/CD для DNS Here comes https://github.com/StackExchange/dnscontrol • Поддерживает целый ряд провайдеров «из коробки» через API • Активно развивается и поддерживается StackExchange • Позволяет версионирование конфигурации через Git • Используйте вашу CI-систему для: • выкатывания изменений в DNS • отката • отслеживания истории • unit-тестирования DNS-конфигурации!
63. Итак • Множество надёжных, защищённых, распределённых managed- сервисов с полезными фичами • Оптимизации задержек в резолверах при использовании нескольких managed-сервисов • Средства автоматизации
64. Итак • Множество надёжных, защищённых, распределённых managed- сервисов с полезными фичами • Оптимизации задержек в резолверах при использовании нескольких managed-сервисов • Средства автоматизации Вдобавок, можно сосредоточить свои усилия на чём-то более полезном, чем попытки построить свой Route 53.
65. Три причины не размещать DNS на своей инфраструктуре 1. Отсутствие industry adopted scalable-решения 2. Использование нескольких managed-сервисов одновременно – несложно и снижает задержки
66. Три причины не размещать DNS на своей инфраструктуре 1. Отсутствие industry adopted scalable-решения 2. Использование нескольких managed-сервисов одновременно – несложно и снижает задержки 3.
67. Три причины не размещать DNS на своей инфраструктуре 1. Отсутствие industry adopted scalable-решения 2. Использование нескольких managed-сервисов одновременно – несложно и снижает задержки 3. Демоны.
68. Internet measurement • Мы уже встречались с этим термином ранее, когда говорили про RIPE Atlas • https://www.ripe.net/analyse/internet-measurements
69. Internet measurement • APNIC – один из 5 RIR, отвечающий за Азиатско-Тихоокеанский регион • APNIC DNS measurements
70. APNIC experiment • Пиксель 1x1: https://z.t1000.u953a6ea5.s1448087430.i5112.vxxxx.06ca0.z.dotnxdomain .net/pix.png • TTL: 1 s
71. APNIC experiment • Пиксель 1x1: https://z.t1000.u953a6ea5.s1448087430.i5112.vxxxx.06ca0.z.dotnxdomain .net/pix.png • TTL: 1 s • Пример из лога: 1450151673.887 15-Dec-2015 query: z.t1000.u953a6ea5.s1450151671.i5112.vxxxx.06ca0.z.dotnxdomain.net A • Видно, что запрос шёл две секунды
72. APNIC experiment • Выдержка из лога: 1450151673.887 15-Dec-2015 query: z.t1000.u953a6ea5.s1448087430.i5112.vxxxx.06ca0.z.dotnxdomain.net A 1450151673.887 15-Dec-2015 query: z.t1000.uc86fd1d9.s1447672979.i5112.vxxxx.3b460.z.dotnxdomain.net A 1450151673.887 15-Dec-2015 query: z.t1000.ub46e3821.s1447703026.i5112.vxxxx.0c914.z.dotnxdomain.net A 1450151674.013 15-Dec-2015 query: z.t1000.u953a6ea5.s1448087430.i5112.vxxxx.06ca0.z.dotnxdomain.net A 1450151674.015 15-Dec-2015 query: z.t1000.ub46e3821.s1447703026.i5112.vxxxx.0c914.z.dotnxdomain.net A
73. • Выдержка из лога: 1450151673.887 15-Dec-2015 query: z.t1000.u953a6ea5.s1448087430.i5112.vxxxx.06ca0.z.dotnxdomain.net A 1450151673.887 15-Dec-2015 query: z.t1000.uc86fd1d9.s1447672979.i5112.vxxxx.3b460.z.dotnxdomain.net A 1450151673.887 15-Dec-2015 query: z.t1000.ub46e3821.s1447703026.i5112.vxxxx.0c914.z.dotnxdomain.net A 1450151674.013 15-Dec-2015 query: z.t1000.u953a6ea5.s1448087430.i5112.vxxxx.06ca0.z.dotnxdomain.net A 1450151674.015 15-Dec-2015 query: z.t1000.ub46e3821.s1447703026.i5112.vxxxx.0c914.z.dotnxdomain.net A APNIC experiment • FROM_UNIXTIME(1450151673) => 2015-12-15 • FROM_UNIXTIME(1447703026) => 2015-11-16 Запрос шёл около месяца?!
74. Демоны • Запрос шёл около месяца? Нет, конечно! • Данные запросы – «зомби-запросы» – были дублями других, отработавших вовремя и успешно
75. Демоны • Запрос шёл около месяца? Нет, конечно! • Данные запросы – «зомби-запросы» – были дублями других, отработавших вовремя и успешно • IP-источники запросов – из сетей Amazon, Team Cymru, Blue Coat Systems • 16% запросов – «зомби»
76. Демоны • DNS – важная часть инфраструктуры Интернета и, по сути, отдельная индустрия. На этом уровне работает целая индустрия игроков, занимающихся анализом трафика и измерениями с одним только им известными целями • Уязвимость DNS к атакам, активность пользователей и особенности работы DNS-серверов не являются для них секретом • Хорошая идея – предоставить обслуживание DNS компаниям, которые зарабатывают на этом и в курсе актуальных угроз
77. Три причины не размещать DNS на своей инфраструктуре 1. Отсутствие industry adopted scalable-решения 2. Использование нескольких managed-сервисов одновременно – несложно и снижает задержки 3. Демоны! Спасибо!
78. Misc [ • можно добавить про CAA, Wikileaks, DNSSEC и выбор TLD, но нужно отталкиваться от времени • http://www.bortzmeyer.org/observations-wikileaks.html • https://www.eff.org/files/2017/08/02/domain_registry_whitepaper.p df • Ещё можно рассказать, как строить резолвер для внутренних сервисов ]