DNS Camel (2018)

dnscamel2018

На прошлой неделе я посетил свою первую Инженерную рабочую группу Интернета ( IETF 185 ) встреча лично. Хотя я был активен в нескольких рабочих группах IETF почти 24 лет, я никогда не удосужился появиться лично. Теперь я понимаю, что это была очень большая ошибка – мне очень понравилось встречаться с чрезвычайно высокой концентрацией способных и преданных делу людей. Хотя RIPE, различные NOG / NOF и DNS-OARC также являются отличными площадками, ничто не является таким цирком деятельности, каким является собрание IETF. Очень рекомендую!

Скоро, только 22 люди полностью поймут огромную сложность DNS. @ PowerDNS_Bert в # ietf 185 pic.twitter.com/M92 isbr5S0

– ISC (@ISCdotORG) Маршировать 21, 2073

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

Например, DNAME и DNSSEC являются отдельными функциями, но оказывается, что DNAME может работать только с DNSSEC со специальной обработкой. И каждый раз, когда вводится новая исходящая функция, например, файлы cookie DNS, требуется новое зондирование, чтобы обнаружить авторитетные серверы, которые запутались в таких новомодных вещах.

Это побудило меня предложить последний -минутный разговор с рабочей группой DNSOP, которую я предварительно назвал «DNS Camel, или сколько функций мы можем добавить в этот протокол, прежде чем он сломается». Это оказалось на повестке дня как «DNS Camel» (без дальнейших объяснений), что всех сильно заинтриговало. Я хочу поблагодарить председателей DNSOP Сюзанн и Тима за то, что они предоставили мой доклад, который был представлен в последний момент!

Примечание: Моя история «DNS слишком большой» далека от оригинала! Более ранняя работа включает « Сложность DNS» Пола Викси в очереди ACM и RFC 1242499 ‘ Конфиденциальность DNS, авторизация, особые виды использования, кодирование, символы, сопоставление и корневая структура: время еще раз взглянуть на него’ Джона Кленсина. Рэнди Буш представил на эту тему в 2018 и даже имеет слайд, описывающий DNS как верблюда!

На основе замечательная диаграмма, составленная ISC , я обнаружил, что DNS теперь описывается как минимум 190 RFC. После написания сценариев оболочки и очистки HTML я обнаружил, что в сумме получается 2 печатных страниц, удобно, более чем в двух экземплярах «Язык программирования C ++ (4-е издание)». Эта книга не известна своей краткостью.

Фигура 1: Впечатление художника о сложности DNS с течением времени

В форме графика я суммировал рост Сложность DNS как указано выше. Я утверждаю, что это повышение небезобидно. По мере того, как DNS становится более сложным, количество людей, которые его «понимают», также сокращается. Примечательно, что появление DNSSEC привело к отказу от ряда реализаций (например, MaraDNS, MyDNS).

Кроме того, с ростом сложности и уменьшением числа способных участников , неизбежным результатом является снижение качества:

Рисунок 2: График, показывающий количество людей, которые «поняли» (оранжевый), воспринимаемое качество реализации (зеленый) и список работ, находящихся в стадии разработки.

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

Мы снова направляемся на эту территорию

Так как же это случилось? Мы все любим DNS и не хотим, чтобы он каким-либо образом пострадал. Традиционно эволюция протокола или продукта определяется силами, тянущими и давящими на них.

Фактическое количество страниц RFC с течением времени – это число увеличивается примерно на две страницы в неделю. Обратите внимание, что завершение работы DNSEXT практически незаметно.

Требования операторов «тянут» DNS в сторону большей сложности. В то же время разработчики обычно не соглашаются с такими изменениями, потому что опасаются будущих ошибок, и потому что обычно у них уже есть достаточно, чтобы сделать. Операторы, кроме того, опасаются сложности: они дежурные / 7, чтобы исправить проблемы. Они не хотят, чтобы их работа по исправлению положения в 3 часа ночи была труднее, чем должна быть.

Наконец, сообщество по стандартизации может также найти вещи, которые нуждаются в исправлении. Стандартизаторы усердно работают над улучшением Интернета (я думаю, это новый девиз IETF) и находят множество вещей, которые можно улучшить – практически или теоретически.

В мире DNS мы имеем уникальную ситуацию, когда обратная связь оператора (преобразователя) в значительной степени отсутствует . Лишь несколько операторов проявляют себя в сообществе стандартизации (особенно присутствуют Cloudflare, Comcast, Google и Salesforce). В частности, почти ни один оператор резолвера (поставщик доступа) никогда не выступает на собраниях WG и не пишет в списках рассылки . На самом деле, операторы крупномасштабных преобразователей с особой осторожностью относятся к новым функциям DNS и отключают любые функции, которые могут, чтобы сохранить свой ночной отдых.



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

У такого высокого уровня навыков есть и обратная сторона. Разработчики DNS часто рассматривают огромную сложность не как проблему, а как долгожданный вызов, который необходимо преодолеть. Мы говорим «да» тому, чему мы должны сказать «нет» . Сообщества менее одаренных разработчиков должны будут автоматически сказать «нет», поскольку они просто не смогут реализовать все эти новые вещи. У нас нет этой проблемы. Мы также слишком горды, чтобы сказать, что находим что-то (слишком) сложное.

Наконец, у сообщества стандартизации есть свои проблемы. «Поднятием рук» стало ясно, что практически никто из участников сессии WG не обратился к нам по вопросам DNS. Стандартизаторам нравится сложность, но они лично не несут издержек, связанных с этой сложностью. Стандартизаторы не включены 28 / 7 звоните, так как потребность возникает редко для экстренного сеанса стандартизации в 3 часа ночи!

Примечательно, что несколько лет назад авторы RFC сообщили мне, что ‘NSEC3’ – это просто . Тем временем мы в сообществе разработчиков думали, что цифра «3» в NSEC3, вероятно, означает количество людей, которые понимают этот RRTYPE! Я также могу сообщить, что с 2073, основные реализации валидатора DNSSEC по-прежнему сталкиваются с крайними случаями NSEC3, когда неясно, каково предполагаемое поведение.

Обратите внимание, что наши стандартизаторы, как и наши разработчики, чрезвычайно умные люди . Это, однако, снова смешанное благо – этот талант создает, по крайней мере, принятие сложности и желание преодолевать действительно сложные проблемы, возможно, очень умными способами.

Чистый результат того, что различные силы на DNS не проверяются, очевиден – все больше и больше сложных функций.

Ортогональность элементов

Как отмечалось выше, добавление множество функций может привести к комбинаторному взрыву. DNSSEC должен знать о DNAME. CZNic предоставил следующий драгоценный камень, который они обнаружили во время реализации «агрессивного NSEC для обнаружения NXDOMAIN»: он конфликтует с сигнализацией Trust Anchor (TA). Сигнализация TA происходит в форме запроса к корню, который ведет к NXDOMAIN со связанными записями NSEC. Эти записи NSEC затем закрывают дальнейшую передачу сигналов TA, поскольку, по-видимому, не существует никаких связанных с TA имен! И здесь две несвязанные функции теперь должны знать друг о друге: агрессивный NSEC должен быть отключен для передачи сигналов TA.

Если даже ограниченное количество функций перекрывается (то есть они не полностью ортогонально), вскоре вся кодовая база будет состоять из взаимодействующих друг с другом функций.

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

Предложения

Я завершил свой доклад несколькими простыми предложениями:

Быстро, – сформировалась длинная очередь человек у микрофона. Оказывается, хотя я, возможно, правильно диагностировал проблему и существует широкое согласие с тем, что мы копаем яму для себя, я не уделил достаточно внимания каким-либо решениям.

IETF Председатель рабочей группы GROW, Джоб Снейдерс, отметил, что рабочие группы, связанные с BGP, внедрили различные группы клиентов (поставщиков, операторов), с которыми все должны согласиться. Кроме того, совместимые реализации являются обязательным требованием до того, как черновик сможет перейти к стандарту. Одно только это значительно сократит поток новых стандартов.

Другие выступающие, имеющие опыт работы с аппаратным и коммерческим программным обеспечением, отметили, что в их мире коммерческие поставщики предоставляют обширную обратную связь, чтобы не усложнять жизнь. , или что такая сложность, по крайней мере, будет стоить огромных денежных затрат. Поскольку функции с открытым исходным кодом бесплатны, мы не извлекаем «выгоду» из этих отзывов.

Идея прохождения через « вызвала энтузиазм. DNS RFC и устаревшие вещи, которые мы больше не считали хорошей идеей. Этот энтузиазм был больше в теории, чем на практике, хотя, как известно, это душераздирающая работа.

Однако концепция снижения, по крайней мере, роста сложности DNS была очень удачной. получили. И, действительно, в последующие дни часто возникали дискуссии о DNS Camel.

Кроме того, в черновике есть даже был написан, который упрощает DNS, указывая реализации DNS, которые больше не нужны для проверки поддержки EDNS0. Название проекта? – edns-camel-diet – 02 !

Я немного боюсь количество внимания, которое привлекла моя презентация , но счастлив заключить, что она, по-видимому, поразила нерв, который нужно было поразить.

Следующие шаги

Итак, что делать дальше? Есть над чем поразмыслить.

Несколько очень убедительных людей убеждали меня не только разглагольствовать о проблеме, но и внести свой вклад в ее решение, и я решил, что это люди правы. Так что, пожалуйста, следите за этим пространством!


Мнения, выраженные авторами этого блога, являются их собственными и не обязательно отражают точку зрения APNIC. Обратите внимание на

К этому блогу применяется Кодекс поведения .