Ад DNS: семь смертных грехов

Общеизвестно во всем Интернете и в локальных сетях повсюду, что «если DNS не доволен, никто не счастлив». Это довольно просто, правда. Жестко программировать приложения для использования фиксированных ip.addrs — это плохо, поскольку они меняются. Таким образом, все, от веб-браузеров ваших пользователей до критически важных бизнес-приложений, должно полагаться на исправную и производительную систему DNS. Проблема в том, что инфраструктура DNS многих организаций далеко не исправна, и это приводит к низкой производительности для всего. Давайте сначала рассмотрим пару концепций DNS.

Геоднс

GeoDNS — это функция BIND и других служб DNS, которая позволяет DNS-серверам давать разные ответы в зависимости от исходного ip.addr запроса. Это работает так. Зона настроена с несколькими записями для ресурсов, таких как www.example.com. Контент этого веб-сайта реплицируется на серверах по всему миру и, вероятно, использует глобальные CDN, контент которых также реплицируется на серверах по всему миру. Когда запрос попадает в DNS для www.example.com или images.example.com, DNS-сервер, являющийся авторитетным для зоны example.com, просматривает исходный ip.addr запроса DNS, определяет, откуда пришел этот запрос, и предоставляет ответ, который включает ip.addrs, которые являются «локальными» для запроса. Это не идеальная система, и часто компании перераспределяют диапазоны IP-адресов без обновления баз данных, но в целом она работает очень хорошо. Вот практический пример.

Скажем, вы находитесь во Франции и найдите www.example.com, конечная точка которого находится в Австрии, а другая — в США. DNS example.com использует GeoDNS. Если ваш DNS-запрос попадает на серверы example.com из NAT ip.addr вашего офиса во Франции, они дадут вам ip.addr для австрийского сервера. Но если DNS-серверы французского офиса настроены на пересылку в штаб-квартиру в США, то то, что DNS-серверы example.com воспринимают как запрос www, исходит из NAT ip.addr центра обработки данных в США, поэтому они отвечают с сервером в США. Вместо быстрого времени отклика на ваши HTTP-запросы в 30 миллисекунд вам придется пересечь Атлантику и бороться с видео с кошками, и, вероятно, вы увидите время отклика больше похожее на 150 миллисекунд. Плохо.

Чтобы ваша сеть правильно использовала преимущества GeoDNS, вы должны убедиться, что для внешних зон ваши пользователи используют DNS-сервер, который находится рядом с ними, и что DNS-сервер должен иметь возможность выполнять свои собственные запросы для внешних зон, переходя к корневому каталогу., без переадресации через вашу глобальную сеть на другие DNS-серверы в другой части мира. Это не только экономит время и пропускную способность глобальной сети, но и гарантирует, что при наличии локальных ресурсов вы получите локальные для вас ip.addrs.

Использование рута

Якорь DNS состоит из 13 серверов с именами от A до M.root-servers.net, на которых размещена корневая зона. Эти серверы обслуживаются 12 различными организациями и распределены по всему миру. Они не разрешают каждую запись для каждой зоны в DNS, но разрешают полномочные серверы для каждого домена в Интернете. Когда ваш DNS-сервер может «уйти в корень», вместо переадресации к вашему интернет-провайдеру или в вашу штаб-квартиру он делает прямой запрос на один из корневых серверов, чтобы найти авторитетные серверы для зоны, а затем запрашивает эти авторитетные серверы. для разрешения записей A, CNAME, MX и других для этой зоны. Такое разрешение домена в первый раз занимает немного больше времени, но ваш DNS-сервер может кэшировать идентификационные данные полномочных серверов зоны, а TTL в их записях обычно длится несколько часов или дней. Пока по крайней мере записи NS для домена уже находятся в кеше, вы должны увидеть, что разрешение для любых других записей завершено менее чем за 50 миллисекунд. Записи, уже кэшированные в памяти вашего DNS-сервера, определенно разрешатся менее чем за 25 миллисекунд. Поскольку у DNS должна быть начальная точка, DNS-серверы используют файл, называемый файлом «корневых подсказок», в котором перечислены 13 корневых серверов и их IPv4 и IPv6 ip.addrs, чтобы служба DNS знала, с чего начать.

Независимо от того, смотрите ли вы на свои удаленные офисы, или на своего провайдера веб-фильтрации, или даже на то, как вы разрешили этот веб-сайт, проверьте свою инфраструктуру DNS сегодня, чтобы убедиться, что вы не совершаете один из этих семи смертных грехов:

1. Нет локального DNS

Я вижу это почти каждую неделю у того или иного клиента. У них есть офисы по всему миру, пользователи жалуются на низкую производительность, и когда мы идем устранять неполадки в сети, мы обнаруживаем, что в офисе нет локального DNS-сервера. Даже если лучшее, что вы можете сделать, — это кэширующий DNS-сервер на маршрутизаторе в небольшом полевом офисе, это лучше, чем ничего, и поможет повысить общую производительность для всех. Разрешение DNS не должно занимать более 25 миллисекунд; 50 вершин. Если каждый раз, когда пользователю необходимо подключиться к принтеру, контроллеру домена, файловому серверу или открыть веб-страницу, ему приходится ждать сотни миллисекунд, пока ответ DNS вернется из удаленного офиса, тогда пользователь будет обратите внимание, что все идет «медленно». Убедитесь, что у вас есть локальные DNS-серверы в любом офисе, который достаточно велик, чтобы иметь оборудование, способное работать с DNS.

2. Настройка переадресации в главный офис

Это распространенная проблема среди крупных компаний, особенно с глобальным масштабом. Они настраивают DNS-серверы в каждом из своих регионов, а затем настраивают эти DNS-серверы для переадресации на DNS-серверы в штаб-квартире или основном центре обработки данных. Поскольку все больше и больше поставщиков SaaS и крупных веб-сайтов развертывают распределенные конечные точки и используют глобальные CDN для повышения производительности для пользователей, это становится большей ошибкой. Плохие решения по выходу могут сделать ситуацию еще хуже — подробнее об этом см. ниже.

3. Использование DNS вашего интернет-провайдера

Итак, вы меняете переадресацию своих DNS-серверов в офисе, чтобы не перенаправлять на DNS-серверы штаб-квартиры по другую сторону океана. Это хорошо. Поэтому вместо этого вы пересылаете их своему интернет-провайдеру, потому что так лучше. Только это очень часто не так. IP-адреса, которые дает вам ваш провайдер, вполне могут НЕ принадлежать к тому же региону, что и вы, или сами они могут быть настроены для переадресации в другой регион. Единственный раз, когда я чувствую себя комфортно, используя DNS-серверы провайдера, это дома, а я даже не делаю этого дома! Если вы абсолютно уверены, что DNS-серверы вашего интернет-провайдера являются локальными для вас, и они не перенаправляют на какие-либо удаленные серверы, то это нормально, но следите за временем отклика и подумайте о том, чтобы позволить вашим локальным DNS-серверам получить root права самостоятельно.

4. Использование общедоступного DNS

Таким образом, вместо использования DNS вашего интернет-провайдера вы решаете использовать одну из общедоступных служб DNS, предоставляемых Google, или OpenDNS, FreeDNS, вашего поставщика защиты от вредоносных программ или одного из интернет-провайдеров уровня 1, таких как Level3 или Hurricane Electric. К сожалению, здесь может возникнуть та же проблема. Часто эти общедоступные адреса ip.addrs находятся не в том же регионе, что и вы, поэтому вам снова приходится разрешать имена в ip.addrs, которые не являются вашими локальными. Опять же, я бы порекомендовал вам позволить вашим локальным DNS-серверам самостоятельно выполнять root-права, а не заниматься переадресацией.

5. Не обновлять корневые ссылки

Возможно, вы читали это до сих пор и чувствуете себя довольно хорошо, потому что вы не пересылаете на удаленные серверы и разрешаете своим локальным серверам обращаться к root. Замечательно! Но когда вы в последний раз обновляли файл корневых подсказок? Кто угодно? Кто угодно? Бьюллер? Файл named.root, поддерживаемый Internic, последний раз обновлялся 20 октября 2016 г. Они не часто обновляют его, но когда это происходит, очень важно, чтобы все администраторы DNS, использующие корневые ссылки, обновляли свои локальные файлы корневых ссылок на всех своих DNS-серверах, добавляя последнюю информацию. Если вы не сделали этого за последние несколько месяцев, зайдите в Internic и проверьте обновленный файл.

6. Выход из одного пути, выход из другого

Вот огромная (осмелюсь сказать, оооочень) проблема, с которой я постоянно сталкиваюсь у клиентов. У них есть локальный выход в Интернет, но у них настроена переадресация DNS на удаленные серверы, или у них есть выделенные пути к ресурсам SaaS или PaaS в одном месте, но не в другом. Отменяя все вышесказанное о локальном DNS, вам необходимо убедиться, что ваше разрешение DNS идет по тому же пути, что и ваш интернет-трафик. Если вы разделяете этот путь так, что один выход в Интернет является локальным (прямым или через прокси-сервер), а другой выход в Интернет выходит за пределы выделенного канала к внешнему поставщику, вам может потребоваться настроить условную переадресацию, чтобы гарантировать, что разрешение DNS и маршрутизация исчерпаны. тот же выход для удаленных ресурсов. В противном случае вы можете обнаружить, что разрешаете локальную конечную точку, но направляете свой трафик через полмира, прежде чем он сможет выйти из вашей сети, чтобы вернуться к локальному ресурсу, а затем обратно.

7. Удаленные прокси

На рынке есть несколько прокси-решений, которые предоставляют прокси «в облаке» или в центрах обработки данных поставщика услуг. Если вы используете один из них, вы должны убедиться, что поставщик услуг не только предлагает вам локальные прокси-узлы, но и не допускает тех же ошибок DNS при переадресации, что и выше. Я снова и снова видел, как клиент использует облачный прокси-сервер и пытается получить доступ к сервису SaaS в своем регионе и имеет очень низкую производительность. Когда мы работаем с поставщиком SaaS для диагностики подключений от прокси-сервера, мы определяем, что сам прокси-сервер подключается к конечным точкам на другой стороне планеты, а не к локально размещенным ресурсам, и все сводится к переадресации DNS узлов прокси. на вышестоящие серверы в другом регионе.

Практически каждое отдельное соединение с одного хоста на другой начинается с DNS-запроса. Все больше и больше поставщиков услуг и CDN переходят на подход GeoDNS, чтобы помочь распределить ресурсы по всему миру и предоставить клиентам наилучший ответ. Администраторы DNS должны внести свой вклад в обеспечение того, чтобы клиенты получали быстрые и надлежащие ответы на свои запросы. Потратьте время на проверку своей DNS-инфраструктуры, чтобы убедиться, что вы не совершаете один из семи смертных грехов.