Edns client subnet что это

Edns client subnet что это

EDNS-Client-Subnet (ECS) is a draft informational RFC that uses the EDNS0 extensions to the DNS. Recursive DNS services that support ECS can provide the client (end-user) subnet as part of the DNS query, allowing authoritative DNS providers to use this extra information to make more informed traffic routing decisions.

Dyn released ECS support for Traffic Director in early September 2015.

FAQ of Dyn’s ECS Implementation

Q. What is the basis of Dyn’s ECS implementation?

Dyn’s implementation is based off of the latest EDNS-Client-Subnet informational RFC draft as of this writing (mid September 2015).

Q. Which Dyn customers have access to ECS?

Dyn customers who is using our Traffic Director service can enable and take advantage of ECS.

Q. How can I enable ECS on Traffic Director?

ECS is disabled by default. To enable this feature, please contact our helpful Technical Support team to assist you. When you contact them, please have a list of Traffic Director zones where you want ECS enabled ready to provide to the team.

Once the ECS option is enabled on each zone, it should propagate across the edge shortly. Once propagated, any Traffic Director instance with ECS implemented should begin taking advantage of ECS-enabled DNS Queries.

Q. Which Recursive DNS providers include ECS information in DNS queries?

As of this writing, the only known recursive DNS providers who include ECS information in DNS queries are:

Google Public DNS
OpenDNS

Google Public DNS and OpenDNS comprise of

20% of worldwide DNS traffic according to some reports.

Q. What happens when a DNS query is received without ECS information?

DNS queries without ECS information will be processed the same way they are today. This is the more likely scenario since the majority of recursive DNS servers today do not provide ECS information.

Q. What happens when a DNS query for a Traffic Director instance is received with ECS information?

When a DNS query is received by our nameservers, we analyze the query in order to determine what response we provide. During this analysis, we will notice if ECS information is provided and whether a Traffic Director service will be involved in the response. If both is the case, we will use the ECS information for our geolocation lookup instead of the source IP address.

Once a geolocation is found and a response is selected, Traffic Director will provide a DNS response back to the source IP address. As part of this response we will include information via ECS regarding what subnet the response should be cached for.

For example, if a DNS query includes ECS information for 192.168.1.0/24 and the response uses Traffic Director, a response could request that it be stored for the 192.168.1.0/24 subnet in the cache. If 192.168.1.0/24 is actually part of a larger /20 block, Traffic Director could respond back with instructions to cache the response for 192.168.1.0/20. If it turns out we have no special response that requires per subnet caching, we would return a /0 so it is cached for everyone.

The recursive DNS server will then cache that response for the appropriate subnet and respond with that cached response for any client that falls within that subnet.

Q. What happens if a DNS query is received with ECS information and on a zone that has ECS activated, but no Traffic Director instance is involved?

We will notice that the DNS query is for a record that doesn’t use Traffic Director and return a DNS response that tells the recursive to cache the response for everyone (specifically, that the subnet is a /0).

Q. What is the cost of enabling ECS?

There is no direct fee for enabling ECS. However, enabling ECS will likely increase the QPS (Queries Per Second) sometimes significantly, on Traffic Director zone(s) where ECS is enabled. This is due to the increased queries from supporting recursives as their caches are less useful.

Depending on your current QPS usage, this could result in additional overage charges. Please contact your Account Manager with any questions.

NOTE: The QPS increase should only be seen on records within Traffic Director instances. Any non-Traffic Director records should not see a QPS increase.

Источник

В России сохраняются проблемы с доступностью сайтов, но никто их не замечает

TL;DR: Из-за блокировок Роскомнадзора большое количество ресурсов, находящихся на Amazon CloudFront и Akamai, периодически становятся кратковременно недоступны. Проблема вызвана частой сменой (ротацией) IP-адресов на доменах, использующих эти сервисы, а также балансировками на основе геопризнака и EDNS Client Subnet: периодически DNS-серверы ресурсов выдают клиентам адреса, внесённые в Реестр запрещенных сайтов. Неосведомлённому человеку сложно определить причину проблемы, так как через минуту всё, как правило, снова работает (но через какое-то время опять перестаёт).

Введение

Около двух лет в России в рамках борьбы с Telegram были заблокированы диапазоны IP-адресов Amazon Web Services, CloudFlare, Digital Ocean, Scaleway, Hetzner, Softlayer и других менее известных хостингов и CDN. Перечисленные сервисы очень популярны, их услугами пользуется значительное количество сайтов в интернете.
Во времена блокировки пользователи сообщали о недоступности Playstation Network, Viber, Spotify, основного сайта Microsoft и некоторых его поддоменов, а также множества других сервисов, сайтов и интернет-игр.
18.06.2020 Роскомнадзор разблокировал все ранее блокированные диапазоны, жалобы на недоступность сайтов резко сократились.

Однако часть сайтов, использующих сервисы Amazon CloudFront и Akamai, до сих пор периодически не открывается либо не загружается полностью, а через минуту уже работают нормально. Вы могли списывать такое поведение на проблемы у интернет-провайдера или сайта, но на деле они вызваны интернет-блокировками в России и особенностями геобалансировки этих сервисов.

Вот краткий список хостов, к которым был затруднен доступ за последние 2 недели:

Геобалансировка и EDNS Client Subnet

Отрезолвим домен steamcommunity-a.akamaihd.net (домен Steam для изображений и различных ресурсов) через DNS-резолвер Google 8.8.8.8, используя диапазоны 87.245.224.0/24, 87.245.225.0/24, 87.245.226.0/24, 87.245.227.0/24 провайдера retn для Client Subnet:

Подождем пару минут, повторим опыт:

Как легко заметить, для каждого диапазона отдаются разные наборы адресов, которые меняются со временем.

Один из IP-адресов, 92.123.77.19, находится в Реестре запрещенных сайтов с 22.10.2020. При попытке браузера открыть сайт через этот IP-адрес, он либо сразу не откроет страницу, либо будет загружать её бесконечно долго (зависит от системы блокировок у провайдера).

Аналогичная ситуация наблюдается со многими другими доменами. Например, leonadro.osnova.io (изображения новостных сайтов tjournal.ru, dtf.ru) периодически резолвится в 2.19.204.32, 2.16.103.18, один из которых находится в Реестре.

Пример выполнения команды nslookup под Windows, используя DNS-резолверы провайдера ОнЛайм (Москва):

История выявления проблемы

Пользователи АнтиЗапрета и расширения «Обход блокировок Рунета» визуально уведомляются о факте проксирования домена или IP-адреса, а при ошибке проксирования им предоставляется возможность отправки сообщения об ошибке.

При наличии домена проксирование всегда осуществляется по нему; на прокси-сервер не отправляется IP-адрес, полученный через DNS-резолвер пользователя.
Ошибка возникала из-за того, что локально у пользователя домен резолвился в заблокированный IP-адрес, из-за чего запрос, содержащий только домен, отправлялся на прокси-сервер проекта. Прокси-сервер искал домен по списку заблокированных, не находя его там резолвил IP-адреса, получал другой набор IP-адресов (не тот, который был у клиента), и блокировал запрос из-за отсутствия IP-адресов в Реестре заблокированных.

Возможные решения проблемы

[…] Мы сделали сразу два решения проблемы с блокировкой популярных ресурсов.

Первый способ — интеграция с DNS-серверами для избежания частичных блокировок.

У некоторых больших ресурсов и сервисов, таких как Google, на одном домене используется большое количество IP-адресов. Некоторые из них могут случайно оказаться в списках на блокировку. В итоге абоненты испытывают проблемы, сайт у них открывается со второй или третьей попытки, пока браузер перебирает IP-адреса, возможно он так и не подключится. С помощью Carbon Reductor DPI X Вы можете настроить интеграцию с Вашим DNS-сервером и отдавать клиентам только незаблокированные IP-адреса.

Если абонент использует публичные DNS-сервера этот способ не поможет. При обращении в поддержку можно рекомендовать ему использовать DNS-сервер провайдера или Вы можете настроить переадресацию DNS на маршрутизаторе.
[…]

Готовое ПО с подобной функциональностью мне неизвестно, но это достаточно просто реализовать в Knot Resolver и PowerDNS Recursor.

В простых случаях должно быть достаточно добавить незаблокированные адреса для домена в файл hosts, но на мобильных устройствах это невозможно сделать без root или специального ПО.
Владельцы сайтов могут попробовать отключить геобалансировку и изменение IP-адресов, если такая настройка имеется, либо установить и использовать для домена собственный DNS-сервер, настроенный таким образом, чтобы отдавать только гарантированно не заблокированные адреса.

Источник

Русские Блоги

С учетом сложности и разнообразия услуг, формат сообщения DNS, определенный в RFC1035, и содержание сообщений, которые он поддерживает, более не являются достаточными для удовлетворения потребностей некоторых DNS-серверов. Поэтому в RFC2671 предлагается расширенный механизм DNS EDNS (Механизмы расширения для DNS). ), И рекомендует EDNS0, который передает размер пакета. Я кратко опишу некоторые ключевые материалы EDNS0 в этой статье, чтобы я мог прочитать их в будущем. В то же время я надеюсь помочь таким новым людям, как я, которые в течение долгого времени были сбиты с толку, изучать EDNS и знать его обзор.

ОдинЧто такое EDNS?

EDNS следит за существующимФормат сообщения DNSНа основе добавления некоторых полей для поддержки большего количества бизнес-запросов DNS.

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

ДваЗачем там должно быть EDNS?

RFC2671 указал на несколько причин, по которым было предложено EDNS:

(1) заголовок протокола DNSВторые 16 байтовВсе они были использованы, и для поддержки других требований необходимо добавить новые типы возврата (RCODE) и теги (FLAGS);

2) Только два тега назначены тегам, которые указывают тип домена. Теперь используются два бита (00 указывает тип строки, а 11 указывает тип сжатия). Если есть больше типов тегов позже, они не могут поддерживаться;

3) В исходном протоколе DNS размер пакета при передаче пакетами UDP был ограничен 512 байт. Теперь многие хосты имеют возможность собирать большие пакеты данных, поэтому должен быть механизм, позволяющий запрашивающей стороне DNS уведомлять сервер DNS, чтобы он мог вернуть большой размер. пакет;

В будущем мы увидим, что механизм DNSSEC и механизм edns-client-subnet должны поддерживаться EDNS.

триЧто такое содержание EDNS?

Как добавить несколько полей на основе протокола сообщений DNS? Для обеспечения обратной совместимости невозможно изменить существующий формат протокола DNS, поэтому вы можете создать статью только в части данных протокола DNS.

Поэтому в EDNS введена новая запись псевдоресурса OPT (Resource Record), которая называется записью псевдоресурса, поскольку не содержит данных DNS. OPT RR нельзя кэшировать, пересылать или хранить в файле зоны. в. OPT размещается на DNS-сообщениях обеих сторон (запрашивающая сторона и ответчик).Additional dataВ области.

1. Каково содержимое записи псевдоресурса OPT?

Содержимое в OPT псевдо-RR содержит фиксированную часть и переменную часть. Его структура выглядит следующим образом:

Рисунок 1 Содержание OPT

Исходное поле TTL используется для хранения RCODE и флагов в расширенном заголовке сообщения и имеет следующий формат:

Рисунок 2 Рисунок 2 расширенный RCODE и флаги Подробнее

Верхние 8 битов на рисунке 2 представляют собой расширенный RCODE (код состояния возврата). Эти 8 битов плюс 4 бита в заголовке DNS имеют в общей сложности 12 битов (8 битов в верхних битах), так что можно выразить больше типов возврата;

Поле VERSOION указывает версию EDNS (EDNS будет иметь много версий в соответствии с различными поддерживаемыми расширениями), содержание, упомянутое в этой статье, имеет VERSION = 0

В RFC2671 отправитель Z обычно устанавливает значение 0, и получатель может игнорировать его. Однако эти 16 бит будут использованы в последующих протоколах расширения.

Структура переменной части RDATA в OPT RR показана ниже:

Рисунок 3 Формат RDATA

Соотношение между тремя вышеупомянутыми диаграммами может быть более ясным, если взглянуть на следующую диаграмму:

Следует отметить, что в каждом сообщении DNS может быть только одна запись псевдоресурса OPT. При наличии нескольких протоколов расширения EDNS каждая пара <атрибут, значение>сохраняется в RDATA по одному. Как показано ниже

Можно видеть, что, когда есть NSID и CSUBNET, два RDATA тесно расположены в поле RDATA OPT, и общая длина обоих определяется длиной данных.

2，example

Итак, горькая теория, давайте посмотрим на формат EDNS0 на примере!

Я использую dig в bind-9.8.1-p1 на своем компьютере, чтобы запросить домашнюю страницу Google, и задаю для параметра размера пакета значение 768:

./dig www.google.com.hk +bufsize=768

Используйте tcpdump для захвата пакета, а затем используйте ethereal для просмотра содержимого пакета UDP. На следующем рисунке приведено подробное содержимое пакета запроса:

Рисунок 4 запросное сообщение

Синим цветом на рисунке 4 является все содержимое дополнительных данных в сообщении запроса. Мы можем видеть, что существует OPT RR. Следует отметить, что:

1) Расширенные значения RCODE, VERSION и Z в поле TTL делятся на эфирные для отображения;

2) Длина RDATA равна 0, что указывает на отсутствие сообщения о переменной RDATA. Из следующего сообщения видно, что RDATA отсутствует (. )

На следующем рисунке показано ответное сообщение:

Рисунок 5 ответное сообщение

Как видно на рисунке 5, в дополнение к подробной информации о четырех авторитетных серверах доменных имен Google в разделе Дополнительные данные есть OPT RR, а размер пакета ответного сообщения составляет 4096 байт.

3，Others

RFC2671 также содержит много вопросов, на которые следует обратить внимание запрашивающей стороне и респонденту при внедрении EDNS0, а также проблемы, вызванные EDNS0. Те, кто заинтересован в них, могут двигаться.Вот。

Источник

Passing the source address to the backend¶

dnsdist, as a load-balancer, receives the UDP datagrams and terminates the TCP connections with the client. It therefore knows the source IP address and port of that client, as well as the original destination address, port, and protocol. Very often the backend needs to know that information as well, to pass EDNS Client Subnet to an authoritative server, to do GeoIP-based processing or even custom filtering.

There are several ways to pass that information using dnsdist: EDNS Client Subnet, X-Proxied-For and the Proxy Protocol.

Using EDNS Client Subnet¶

EDNS Client Subnet (ECS) is a standardized EDNS option designed to pass a bit of information about the client from a resolver to authoritative servers. While it was not designed with our use-case in mind, it can be used by dnsdist to send the source IP, but only the source IP, to its backend.

In addition to the global settings, rules and Lua bindings can alter this behavior per query:

In effect this means that for the EDNS Client Subnet option to be added to the request, useClientSubnet should be set to true for the backend used (default to false ) and ECS should not have been disabled by calling SetDisableECSAction() or setting dq.useECS to false (default to true).

Note that any trailing data present in the incoming query is removed when an OPT (or XPF) record has to be inserted.

In addition to the drawback that it can only pass the source IP address, and the fact that it needs to override any existing ECS option, adding that option requires parsing and editing the query, as well as parsing and editing the response in most cases.

X-Proxied-For¶

The experimental XPF record (from draft-bellis-dnsop-xpf) is an alternative to the use of EDNS Client Subnet which has the advantages of preserving any existing EDNS Client Subnet value sent by the client, and of passing along the original destination address, as well as the initial source and destination ports.

If the incoming request already contains a XPF record, it will not be overwritten. Instead a new one will be added to the query and the existing one will be preserved. That might be an issue by allowing clients to spoof their source address by adding a forged XPF record to their query. That can be prevented by using a rule to drop incoming queries containing a XPF record (in that example the 65280 option code has been assigned to XPF):

Proxy Protocol¶

The Proxy Protocol has been designed by the HAProxy folks for HTTP over TCP, but is generic enough to be used in other places, and is a de-facto standard with implementations in nginx and postfix, for example. It works by pre-pending a small header at the very beginning of a UDP datagram or TCP connection, which holds the initial source and destination addresses and ports, and can also contain several custom values in a Type-Length-Value format. More information about the Proxy Protocol can be found at https://www.haproxy.org/download/2.2/doc/proxy-protocol.txt

dnsdist 1.5.0 only supports outgoing Proxy Protocol. Support for parsing incoming Proxy Protocol headers has been implemented in 1.6.0, except for DoH where it does not make sense anyway, since HTTP headers already provide a mechanism for that.

Both the PowerDNS Authoritative Server and the Recursor can parse PROXYv2 headers, if configured to do so with their proxy-protocol-from setting.

Influence on caching¶

When dnsdist’s packet cache is in use, it is important to note that the cache lookup is done after adding ECS, because it prevents serving the same response to clients from different subnets when ECS is passed to an authoritative server doing GeoIP, or to a backend doing custom filtering. However that means that passing a narrow ECS source will effectively kill dnsdist’s cache ratio, since a given answer will only be a cache hit for clients in the same ECS subnet. Therefore, unless a broad ECS source (greater than 24, for example) is used, it’s better to disable caching.

One exception to that rule is the zero-scope feature, which allows dnsdist to detect that a response sent by the backend has a 0-scope ECS value, indicating that the answer is not ECS-specific and can be used for all clients. dnsdist will then store the answer in its packet cache using the initial query, before ECS has been added. For that feature to work, dnsdist will look up twice into the packet cache when a query arrives, first without and then with ECS. That way, when most of the responses sent by a backend are not ECS-specific and can be served to all clients, dnsdist will still be able to have a great cache-hit ratio for non ECS-specific entries.

That feature is enabled by setting disableZeroScope=false on newServer() (default) and parseECS=true on newPacketCache() (not the default).

Things are different for XPF and the proxy protocol, because dnsdist then does the cache lookup before adding the payload. It means that caching can still be enabled as long as the response is not source-dependant, but should be disabled otherwise.

Источник

Настройка EDNS0 в Windows Server

Механизм расширений EDNS0, а также OPT Cookies, взаимодействие с DNSSEC и настройка + тестирование всего этого в корпоративной сети

Протокол DNS существует очень давно – с самой зари Интернета – и за время своего бытия оброс множеством дополнительных расширений и дополнений. Про одно из них – EDNS – мы и поговорим сегодня.

Я предполагаю, что на начало чтения статьи Вы знакомы с работой DNS и профильной терминологией хотя бы на уровне базового курса Microsoft 20410D. Настройки буду делать на Windows Server 2012 R2 со всеми патчами – хотя все эти опции идентично работают и реализуемы начиная с Windows Server 2008 R2, а некоторые и ещё раньше. Для настроек буду использовать ATcmd последней версии – Вы можете использовать как эту утилиту, так и любой другой способ/инструмент; способ выполнения действий некритичен.

Настройка EDNS0 в Windows Server

Что такое и зачем нужен EDNS0

Механизм DNS, спланированный и стандартизированный к 1987 году (RFC 1035), безусловно, не мог на момент создания учитывать все перспективные изменения в требованиях, использовании, безопасности и прочем, что неразрывно связано с развитием сети Интернет. Изначально возможностей расширения было заложено в него крайне немного (разве что свои типы RR), поэтому вполне логично, что со временем появилась необходимость в его расширении. EDNS0, появившийся в 1999 году (через 12 лет после стандартизации DNS, RFC 2671), был призван решить этот вопрос, с чем неплохо справляется до сегодняшнего дня – правда, вместо превращения в EDNS1 (драфт которого в природе есть, но вообще не особо кому-то нужен), начал развиваться в ширину, обрастая опциями и применениями – RFC 6891 – но данный процесс для рабочего стандарта вполне нормален.

Что же добавляет EDNS0? В принципе, основным нововведением в нём является добавление нового типа псевдо-записи – OPT. Это специфичный тип RR-записи, которая не несёт DNS-данные (поэтому и “псевдо”), а нужна исключительно для стандартизации обмена служебной информацией. В подавляющем большинстве случаев использования в ней передаётся один блок информации – запись о максимальном обрабатываемом размере DNS-датаграммы.

Данный пункт действительно является важнейшим по простой причине – так как на момент разработки DNS сети были ещё очень медленные, а также в них было множество устаревших на данный момент протоколов канального уровня (сильно различавшихся технически и логически), то датаграмма DNS, в целях повышения её выживаемости в ходе путешествия по Интернету, ограничена размером в 512 байт (чтобы вместе с заголовками транспортного и сетевого уровня не первышать 576 байт). По сути, всё сделано для того, чтобы датаграмма выжила в среде с самым мелким MTU и без поддержки фрагментации. Понятное дело, что в современной ситуации, когда в DNS-ответ может быть добавлена пачка адресов (одно имя теперь часто, для отказоустойчивости, разрешается в несколько адресов сетевого уровня), притом крупных в плане занимаемого места – например, IPv6, ну и всякие дополнительные данные, например DNSSEC’овские RRSIG и DSKEY, да или просто TXT, такое ограничение (“не более 512 байт DNS-данных а то вдруг не дойдёт”) крайне неудобным.

Неприятностей добавляет простая проблема, исходящая из природы UDP – дело в том, что в случае отправки запроса или ответа отправитель, в случае тишины после, никак не сможет понять, что произошло – был ли пакет потерян по случайной причине, или отброшен промежуточным узлом по причине несоответствия максимальному размеру MTU, или потерялся по причине необходимости фрагментации на каком-то отрезке пути, а фрагментация DNS-пакета не получилась, или какой-либо другой. Плюс не надо забывать, что датаграммы от клиента к серверу, а после – в обратном направлении, совершенно необязательно будут идти по одной и той же трассе. В результате возможно множество различных неприятных ситуаций, вида “клиент отправил запрос серверу – сервер отработал, отправив ответ – ответ не дошёл, потому что великоват в части MTU, а клиент ошибочно думает, что сервер технически недоступен”, или “сервер отправил запрос другому серверу – запрос не дошёл, потому что тот сервер не поддерживает EDNS0 – клиент, изначально отправивший запрос, предполагает, что ближайший к нему сервер не работает, т.к. прошёл тайм-аут ожидания ответа”, и многих других. Поэтому понимание и представление о том, как всё это работает, резко помогает понять множество “странных багов DNS”.

Давайте попробуем протестировать работу EDNS0.

Тестим EDNS0 с нашего хоста

Чтобы проверить работоспособность EDNS0, необязательно быть DNS-сервером. Это можно сделать и при помощи утилиты nslookup.

Первым делом – запустим nslookup и скажем, что нас будут интересовать только ответы TXT-типа. Это просто:

Теперь попробуем тестировать более цивилизованным способом.

Тестим EDNS0, используя автоматизированную утилиту ATcmd

Для упрощения тестирования в ATcmd есть диагностический контекст – test, в котором поддерживается несколько типовых сценариев опроса DNS-серверов на предмет поддержки EDNS0:

Это режим local, когда утилита автоматически тестирует все DNS-сервера данного хоста, режим прямого указания одиночного IP-адреса сервера и режим, когда указывается FQDN домена Active Directory – и утилита последовательно подключается к NS-серверам и тестирует их. Данный режим очень удобен для больших предприятий, и позволяет увидеть работоспособность EDNS-обмена с различными серверами с точки зрения конкретного хоста.

В общем, думаю, Вы оценили количество потенциальных проблем, которые будут, если оставить данный вопрос на самотёк – поэтому пора приступать к настройкам работы EDNS0 в сети предприятия.

Включаем EDNS0 на Windows Server

Включение механизма EDNS0 не так очевидно, как кажется. Первое, что надо отметить – Ваш сервер, если это Windows Server 2003 и выше, умеет принимать и обрабатывать EDNS0-ответы – т.е. не пугается ни бОльшего размера датаграммы, ни наличия специфичной OPT-записи. А начиная с Windows Server 2008 R2, механизм EDNS включен по умолчанию. Включать же мы будем, фактически, добавление в запросы другим DNS-серверам дополнительной “тестовой” OPT-записи. Цель – чтобы по их ответу на этот запрос было понятно, поддерживают они EDNS0 или нет.

Для включения этого механизма, EDNS Probes, да и вообще работы с EDNS, у нас будет специальный субконтекст – edns:

Включим механизм командой ednsprobes :

Совет по части этого параметра будет простым – включайте его со стороны своего сервера только убедившись, что “большие” EDNS-ответы технически могут добраться до него снаружи. Ключевое – разница между “наш сервер поддерживает и декларирует остальным серверам, что умеет” и “технически возможно прохождение датаграммы бОльшего размера, чем 576 байт”. Плохо, если Ваш сервер будет всем показывать, что может, но отправляемые ему датаграммы будут теряться, не доходя до него.

Настраиваем максимальный размер датаграммы EDNS0 на Windows Server

По стандарту EDNS0 мы добавляем в каждую DNS-датаграмму специальную RR, которая имеет тип OPT – добавляем в любое место, и только один раз. В этой RR и содержится информация о том, датаграммы какого размера мы можем “переваривать”. Понятное дело, что просто так выставлять этот параметр большИм не имеет смысла и даже вредно – в начале статьи мы выясняли, что фактический размер успешно принимаемой датаграммы зависит, скорее, не от нашего сервера, а от форвардера. Поэтому имеет смысл декларировать такой размер, который проверен экспериментально – я выставлю удвоенный размер стандартной DNS-датаграммы, 1280 байт (этот размер рекомендован в RFC 6891):

Замечу, что при комплексной настройке поддержки EDNS0 сетью, данный параметр, допустим, на сетевых устройствах, надо делать максимально возможным (рекомендуется 4096 байт). Их задача – просто не фильтровать “слишком большие пакеты”, поэтому не удивляйтесь, что корректная настройка будет выглядеть именно так – на промежуточных сетевых устройствах “чем больше, тем лучше”, а на конечном DNS-сервере – “только столько, сколько экспериментально доказано, что влезает, и не более”.

Таблица поддержки EDNS0 у других серверов: настраиваем

Вот все статусы, кроме первого, будут держаться в табличке столько, сколько мы скажем в настройках параметра EDNS timeout. После истечения этого времени статус будет сброшен на Unknown и процесс определения поддерживаемости EDNS0 запустится снова.

Если наш сервер не поддерживает новые расширения DNS

Возможен такой вариант – наш сервер расположен за не управляемыми нами firewall’ами, которые в явном виде не любят, чтобы DNS-пакеты были больше 512 байт. Со своей стороны мы поддержку EDNS0 выключили и поэтому наши пакеты всегда нормально уходят наружу, но вот внешние сервера про такую особенность нашей сети не знают и пытаются присылать нам пакеты с дополнительными опциями. В случае, если наш сервер не понимает, что от него хотят, по умолчанию в нём включается механизм защиты от DoS-атаки “неправильными” DNS-запросами. Механизм работает просто – после приёма пакета, который не удаётся полностью обработать (допустим, в нём неизвестная RR), все другие запросы и ответы с IP-адреса, откуда пришёл этот пакет, не будут обрабатываться целую минуту. В общем-то, данный механизм иногда полезен – но чаще нет; например, если у большой организации на площадке у провайдера стоит свой DNS-сервер, который аккумулирует все форвардинги от внутренних серверов организации, и к нему придёт один такой запрос, то он откажется на минуту обрабатывать все запросы с этого же адреса, а в типовом сценарии этот адрес-источник – это адрес NAT-транслятора, за которым десятки, а то и сотни клиентов. В этом случае DoS сомнителен, и одиночный неправильный пакет можно и просто отбросить, отметив в логах, не останавливая обработку.

Для управления этим в Windows Server тоже есть опция – мы вынесли её в субконтекст EDNS. Выключим эту защиту, чтобы обработка запросов не останавливалась в случае разового malformed packet:

Что внутри у OPT-поля

Давайте посмотрим, что ещё полезного умеет делать EDNS, чтобы не запомнить случайно, что он может только декларировать максимальный обрабатываемый размер датаграммы.

У OPT RR есть двубайтовый заголовок, указывающий назначение OPT. Обычно используется нуль – именно в этой ситуации OPT несёт на себе информацию о максимальном размере датаграммы.

Единица и двойка заняты под черновики “невыстреливших” стандартов DNS Long-Lived Queries и DNS Update Leases, которые были призваны улучшить работу DNS, развивая механизм Service Discovery и улучшая работу динамических обновлений.

Тройка занята расширением NSID – описывается оно в RFC 5001, краткая суть применения – способ идентификации DNS-серверов в кластере (т.е. тот, кто работает с одним IP-адресом DNS-сервера, может добавить OPT RR с NSID и в ответ сервера добавят в таком же виде OPT RR с третьим кодом, где в payload напишут свои уникальные идентификаторы – например, реальные, а не кластерные IP-адреса). Этот стандарт, в отличии от предыдущей пары DNS-SD, принят.

Четвёрка в принципе не занята, но на неё претендует ещё один из механизмов DNS-SD – так называемый Sleep Proxy, механизм работы которого выглядит так – “пусть каждый сервер, который захочет вздремнуть в плане экономии электричества, вышлет на специальный сервер-будильник специальный EDNS-пакет, где укажет свой MAC, на который он готов принять пробуждающий сигнал Wake-on-Lan, и пароль для пробуждения, чтобы не будил кто попало”. Затейливая схема, притом застолблённая фирмой Apple (https://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-07), поэтому будем относиться к ней с осторожностью.

может информировать DNSSEC-сервер о том, какие алгоритмы он, клиент, поддерживает, что, в случае поддержки и кэширования этой информации на DNSSEC-сервере, во-первых резко снижает количество сбойных итераций (нет ситуации “отправляем клиенту всё слабее и слабее хэшированную запись, пока он не сможет переварить принятое”), от чего вырастает скорость работы, во-вторых снижает нагрузку на сервер.

Девятка в OPT отдана под новый стандарт RFC 7314, EDNS Expire, суть которого в том, чтобы помочь корректно отслеживать expire-таймеры в SOA-записях DNS-зон не только в случае двухуровневой иерархии, когда все secondary-сервера забирают зону с authoritative, но и когда существует граф secondary, забирающих зону у других secondary.

Остальные значения, с 10 по 65000 включительно, никак не обозначены – простор для расширений присутствует. В общем-то механизм действительно простой и удобный, поэтому, возможно, что-то ещё полезное сможет появиться в ближайшее время. Значения от 65001 до 0xFFFE будут, по сути, частными – можно свободно использовать их для своих локальных задач, либо каких-то экспериментальных. Например, Google использует их для работы механизма OPT Cookies. Ну а все единички – 0xFFFF – будут зарезервированны для будущих поколений.

Да, и ещё – есть перспективный стандарт по оптимизации работы цепочек DNS-форвардеров: https://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02, который развивают серьёзные парни из Google, Akamai и OpenDNS, но он уже тема для совсем другого разговора.

Заключение

Обычно изучение работы EDNS – например, на авторизованных курсах Microsoft – выглядит как упоминание на одном слайде, вида “это такая штука чтобы датаграммы больше были”. Остальное – почему, зачем, как применять, как тестировать, как анализировать работу, как связано с DNSSEC – остаётся в стороне. Надеюсь, что этой краткой экскурсией в данную технологию, количество “белых пятен” было немножко уменьшено.

Источник