Что лучше для предоставления поддоменов в Azure - подстановочный знак CNAME или DNS на основе API, например Route 53?

Question

Я создаю приложение на Azure, которое требует использования поддоменов для каждого клиента.Субдомены будут предоставлены в процессе регистрации.Поскольку Azure требует использования CNAME для разрешения DNS , я должен выбрать между подстановочным знаком CNAME или добавить каждую запись вручную, используя такой API, как Amazon Route 53

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

Кроме того, я беспокоюсь о предоставлении новых записей DNS CNAME для клиентов в режиме реального времени.Придется ли им ждать истечения срока действия TTL или сразу же будут получены новые записи CNAME для поддоменов?

Спасибо, Даг

Answer 1

DNS-символы - это метаинформация для вашего DNS-сервера. Он никогда не покидает сервер имен и просто предписывает вашему серверу обрабатывать DNS-запросы определенным образом.

Ваши DNS-клиенты или их рекурсивные средства распознавания не знают, не должны знать и не могут * сказать, что вы используете CNAME с подстановочным знаком.

Эта ссылка Serverfault, которую вы имеете, просто означает, что вам будет труднее найти хост, к которому вы можете добавить подстановочный знак.

Если Amazon Route 53 поддерживает подстановочные знаки для CNAMES, это нормально для производства, при условии, что остальная часть сервера соответствует другим DNS RFC. Единственный случай, когда вам следует позаботиться о поддержке подстановочных знаков, - это использование вторичных записей NS у другого поставщика.

Что касается TTL, существует два TTL, на которые следует обратить внимание: TTL подстановочного знака CNAME или статическое CNAME, которое вы создаете. Затем есть TTL-запись A, которая хранится на серверах имен Microsoft, и вы не можете управлять этим. (вы также не можете контролировать истечение NXDOMAIN в MSFT в записи SOA, но это является касательной). При переключении между Prod и DEV необходимо учитывать, что клиенты будут кэшировать запись A до тех пор, пока не истечет запись A , Если вы используете мобильное приложение, то я видел, что эта запись в кеше провайдера сотовой связи длиннее, чем ожидалось, и в некоторых телефонах для кеширования записи A тоже дольше. Иногда способ исправить это - перезагрузить телефон.

Суть в том, что не нужно беспокоиться о CNAME TTL, важна запись A, которой владеет MSFT. Сделайте dig или NSlookup, чтобы увидеть значение. Если вы найдете NameServer, который поддерживает шаблоны, используйте его, но я буду беспокоиться о безопасности и совместимости с другими RFC. Я действительно доверяю только провайдеру DNS моего провайдера (ATT), UltraDNS и Dynect. У Amazon и UltraDNS хорошие отношения. Все, кроме ATT, имеют SOAP API.

Если вы хотите использовать ATT, вы можете использовать их (или другого интернет-провайдера) в качестве вторичного DNS-сервера и сделать его основным NameServer. Затем внесите все изменения в скрытый мастер DNS.

Я занимаюсь DNS, поэтому не стесняйтесь задавать дополнительные вопросы.

* Сноска. Они могут узнать, используете ли вы CNAME, запросив RandomGUID.domain.com. Если они получат тот же ответ, они могут предположить, что вы используете подстановочный знак CNAME.

Answer 2

Я не знаю, сколько DNS-систем поддерживает подстановочные знаки, но я знаю, что сбои DNS-кэша. Поэтому, если пользователь запрашивает новый домен до того, как вы его подготовили (или, возможно, запрашивает что-нибудь из базового домена), ему нужно будет подождать до TTL, прежде чем он сможет увидеть новую запись.