Добавление имени хоста с www в запись TXT на сервере имен делает сайт недоступным - почему?
Один из способов проверки сайтов при использовании инструментов Googles для веб-мастеров - добавить запись TXT на сервер имен, используя имя хоста и добавив предоставленный текст.
Случайно (потому что я просто не знал) я добавил две записи TXT, одну с участием «www» и один без него, чтобы убедиться, что Google примет код (потому что в инструментах для веб-мастеров сайт был введен с «www»).
Произошло следующее: после того, как DNS-записи распространились, сайты больше не были доступны при использовании имени хоста с www. РЕДАКТИРОВАТЬ: Нет конкретного сообщения об ошибке, просто «Сервер не найден».
Зачем? Вероятно, было наивно думать, что формат записи TXT несколько произвольный, но может ли кто-нибудь объяснить шокированному разработчику (= не администратору), почему запись TXT может влиять на то, что должно обрабатываться записями A так разрушительно?
РЕДАКТИРОВАТЬ: Вот пример (но, конечно, его больше нет в сети). Сайт размещен в domainfactory, общем хостере, где можно редактировать настройки DNS (или управлять ими на фабрике домена - в этом случае в столбце Ziel отображается их имя; обычно смешивать записи не проблема):
Это как раз последняя запись, сделавшая сайт недоступным.
Однако сказать мне, что этого не должно происходить, тоже хороший ответ - тогда я могу спросить у хостинг-провайдера.
Простите меня, если я не знаком с nslookup, но я сделал один поиск с и один без www на одном из доменов, которые все еще не работают, и вот результат:
C:\>nslookup www.foo.de
Server: dns2.colt1.inetserver.de
Address: 195.234.228.93
Name: www.foo.de
И второй:
C:>nslookup foo.de
Server: dns2.colt1.inetserver.de
Address: 195.234.228.93
Nicht autorisierende Antwort:
Name: foo.de
Address: 81.20.84.178
Разница в том, что запрос без «www» показал «Nicht autorisierende Antwort:» (вероятно, «неавторизационный ответ»), но правильный IP.
Хорошо, я могу продублировать поведение (BIND 9.6) и считаю, что понял причину:
Если у тебя есть подстановочный знак Рекорд и более конкретная запись TXT, как показано ниже, бьют.
*.test.bsd-box.net. IN A 127.0.0.1
www.test.bsd-box.net. IN TXT "This be a text record, mon!"
но если у вас есть конкретный Запись отлично работает:
*.test.bsd-box.net. IN A 127.0.0.1
www.test.bsd-box.net. IN A 127.0.0.1
www.test.bsd-box.net. IN TXT "This be a text record, mon!"
Таким образом, очевидно, что наличие более конкретной записи (даже другого типа) маскирует подстановочную запись A.
Я не уверен, какова основная логика, которая вызывает подстановочный знак A запись, чтобы не распознаваться, если есть более конкретная TXT или нет, но вы можете просмотреть DNS RFC (и / или источник BIND) для получения более подробной информации.
Потому что это мешает вашему подстановочному знаку ("*") запись. Если у вас есть какие-либо записи для элемента, подстановочный знак больше не соответствует ни одному типу записи.
Из RFC1034, §4.3.3:
RR с подстановочными знаками не применяются… [w] если имя запроса или имя между доменом с подстановочными знаками и именем запроса [известно] о существовании. Например, если RR с подстановочным знаком имеет имя владельца «* .X», а зона также содержит записи RR, прикрепленные к BX, подстановочные знаки будут применяться к запросам для имени ZX (при условии, что нет явной информации для ZX), но не в BX, ABX или X.
Обратите внимание, что пример не соответствует ситуации OP, но правило остается тем же.
Возможно ли, что при редактировании зоны вы случайно удалили A-запись записанного CNAME?
Возможно, было бы полезно взглянуть на ваш полный файл зоны и посмотреть, все ли там все, что вы ожидаете, там все еще?