Comments 12
А есть поддержка RFC2136 aka Dynamic DNS update для лёгкой дружбы с letsencrypt с dns01 верификацией для wildcard сертификатов? Или придется самому костылять с апи?
Увидел звездочку, подумал уже, что DNS стал "запрещенной в России организацией" :)
Если человек использует публичные DNS-серверы, вместо сервера, который получили по DHCP, он попадёт в страну, хостящую этот DNS.
Есть расширение EDNS Client Subnet, но не все его поддерживают...
Так ли это? Точно скажу, что гугл днс придёт к авторитативному серверу с ip ближайшей точки присутствия гугла, хотя при этом весь мир на стороне клиента использует один ip 8.8.8.8. Иначе гугл ломал бы geodns.
Действительно, если покрытие публичного dns провайдера достаточное, то это расширение и не нужно. Благодаря anycast ваш запрос к 8.8.8.8 улетит на ближайший гугловский dns сервер. А тот, в свою очередь, будет обращаться к авторитетному dns серверу с локального ip.
Тут интересный комментарий от представителя Cloudflare, почему они вообще отказались от этого расширения. От себя могу добавить, не представляю как вообще ответы при этом расширении кешировать.
Кэшировать где? Тут большой вопрос, так к примеру если говорить о PowerDNS Recursor, то если ему ответ прилетает от авторитативного сервера с заполненным расширением ecs, то кэш формируется конкретно по маске сети указанной в ecs, но надо понимать, что авторитативный сервер должен уметь заполнять это поле при ответе. К примеру Bind заполняет его всегда маской /0, так что никакого "узкого" кэша на рекурсоре не сформируется. PowerDNS Auth же просто копирует маску из запроса в ответ, соответственно, кэш на рекурсоре будет формироваться соответственно ширине маски запроса. И если прилетит подобный запрос источник которого не попадает под маску имеющегося ответа в кэше, то рекурсор должен начать полноценный резолв. А вообще, по логике, если к примеру рассматривать в качестве авторитативного сам PowerDNS, то маску можно было бы не копировать из запроса, а к примеру, брать её из условий функции view (Аналог view bind или split dns и т.п.).
По поводу комментария Cloudflare:
Нужно заканчивать использовать архаичный инструмент "промежуточный рекурсор", они нужны были на заре становления интернета, когда были большие проблемы со связностью. Сейчас, по хорошему, нужен нормальный полноценный резолвер прямо на клиенте. Тогда бы и с dnssec проблем бы не было (точка верификация находилась бы у клиента, а не где-то посередине) и вся эта возня с DoH/DoT была бы более логичной (возможно немного сложнее, но точно логичнее нежели тупо доверять какой то промежуточной точке).
Эквивалент Route 53 DNS Failover реализовывать будете ?
Будем, но не в том же самом виде. Failover в том виде, в котором он сейчас у Route53, смешивает DNS и мониторинг, это не самое лучшее разделение ответственности.
Переключение на живую реплику лучше делать с помощью отдельного сервиса мониторинга. Мы откроем декларативную API для DNS и предложим триггер по мониторингу. Который, тоже будет.
Когда конкретно мониторинг будет, пока не знаем.
Мы тоже подумываем о том, чтобы написать свой ДНС сервер для своих сервисов. Сейчас пользуемся болгарским ClouDNS и вот чего нам в нём не хватает:
GeoIP с разделением России на регионы. Их база этого не предусматривает совсем. База MaxMind слишком скупа на российские IP.
Мы используем механизмы мониторинга хостов и деактивации записей если хост упал. При таком подходе мы хотим создать А-запись, навесить на неё мониторинг, а затем сделать ALIAS для каждого сервиса, который работает из данной локации. У них это не работает, так как если погасить А, то все ALIAS, которые на неё указывают, продолжают спокойно работать. Они сказали, что это не баг а фича и ALIAS специально кэшируется. ХЗ зачем. У нас более 150 записей и для каждой делать А-запись со своим мониторингом одновременно неудобно и накладно.
Нельзя сделать ALIAS на другой ALIAS.
Сделайте для начала поддержку доменов третьего уровня в публичных геозонах (msk.ru, spb.ru и т.п.) и нормальный обратный ресолвинг. Как править PTR записи для арендованных хостов - неизвестно.
Мы сделали новый DNS*