Назад | Перейти на главную страницу

Распространенное неверное толкование правил DNS при разрешении подстановочных знаков

[Отредактировано для добавления: эта проблема исчезла сама по себе. Я считаю, что виновато разрешение имен Cloudflare. См. Мой ответ ниже]

Вот фрагмент моего файла зоны

*.example.com.      300 IN  CNAME   proxy.herokuapp.com.
foo.example.com.    300 IN  A       111.111.111.111

Если я dig @8.8.8.8 foo.example.com Я получаю ожидаемый ответ:

;; ANSWER SECTION:
foo.example.com.    30  IN  A   111.111.111.111

То же самое и со всеми другими общедоступными DNS-серверами, которые я пробовал.

Однако когда я пытаюсь настроить проверку с помощью Pingdom на URL на foo.example.com вместо этого он отправляет трафик в мое приложение Heroku, на которое ссылается *.example.com RR.

То же самое касается проверок, проводимых на Новая реликвия, Errplane и трафик, генерируемый Heroku само приложение.

Таким образом, с одной стороны, все публичные DNS-серверы интерпретируют файл зоны одним способом. Тем не менее, четыре поставщика услуг интерпретируют это по-разному, один, отличный от стандарта, предложенного RFC 4592.

Мой вопрос: все ли неправы эти уважаемые, зрелые поставщики услуг? Или мне мало?

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

  1. Они не разговаривают с одним и тем же сервером. Либо у вас есть несколько серверов имен аутентификации, и они отправляют разные ответы, либо выполняется консультация с другим набором серверов аутентификации. (у вашей компании есть конфигурация раздельного DNS?)
  2. Некоторые из серверов кэширования имеют более старую запись в кеше.
  3. DNS полностью игнорируется, т.е. запись в файле hosts.

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

Дополнительная информация:

  1. Ответ Эндрю Б (2) является кандидатом: имя разрешалось путем кэширования серверов, которые не обновлялись с тех пор, как я добавил A-запись. Проблема сохранялась более недели, поэтому я не думаю, что это вероятно.

  2. Я поднял проблему с Cloudflare, и ее передали команде инженеров. Недавно они выпустили обновленный код разрешения имен (https://twitter.com/eastdakota/status/351733117003902976)

Я думаю, что понимаю, как работает разрешение имен, немного лучше, чем когда я задавал вопрос. Более вероятно, что была одна причина (ошибка Cloudflare), чем несколько причин (отдельные ошибки в Heroku, NewRelic, Pingdom и Errplane).