Рекурсивный DNS-сервер отвечает CNAME, но не возвращает запись A

688
ryans11

У меня есть рекурсивный DNS-сервер, который перенаправляет на мои основные DNS-серверы, чтобы получить разрешение.

Возьми пример

У меня есть ниже CNAME:

server1.example1.com. 300 IN CNAME server1.example2.com 

И соответствующий А:

server1.example2.com IN A X.X.X.X 

Проблема, с которой я сталкиваюсь, заключается в том, что рекурсивный сервер возвращает только запись CNAME, когда я делаю a, digи не отвечает за запись A. Через дамп TCP я убедился, что первичные файлы определенно возвращают записи CNAME & A рекурсиву, но он, в свою очередь, не возвращает их digкоманде или любому клиенту, указывающему на этот сервер. У меня есть другие рекурсивные серверы имен, и это прекрасно работает. Но, к сведению, похоже, что это происходит только для междоменных CNAMES

 bash-4.1# dig @recurisveserver server1.example1.com.   ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.5 <<>> @recurisveserver server1.example1.com. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49412 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0  ;; QUESTION SECTION: ;server1.example1.com. IN A  ;; ANSWER SECTION: server1.example1.com. 300 IN CNAME server1.example2.com.  ;; Query time: 0 msec ;; SERVER: 10.73.241.88#53(10.73.241.88) ;; WHEN: Mon Mar 5 15:52:31 2018 ;; MSG SIZE rcvd: 76 

Nslookup дает пустой ответ

 > server1.example1.com Server: recursiveserver Address: x.x.x.x  Name: server1.example1.com 
1
[В любом случае, не запутывайте то, что вы публикуете в мире] (http://jdebp.eu./FGA/dont-obscure-your-dns-data.html). Люди не могут проверить это сами и рассказать вам, что происходит. Вы также должны сообщить людям, что такое программное обеспечение прокси-сервера DNS, и как вы его настроили. Существуют _ возможные объяснения этому, но в этом вопросе нет достаточно точной информации, чтобы определить, являются ли они правильными ответами для рассматриваемой ситуации. JdeBP 6 лет назад 0
Вам также нужно сообщить людям IP-адрес. Посмотрите на https://unix.stackexchange.com/questions/417101/ только один пример вопроса, который включает в себя важнейший необъяснимый правильный IP-адрес, который оказался ключом к ответу. JdeBP 6 лет назад 0
«Прокси-сервер DNS» не применяется - OP использует BIND для создания DNS-аутентификации и рекурсии. davidgo 6 лет назад 0
Будучи разрешающим прокси-сервером DNS _is_ прокси-сервером DNS (http://jdebp.eu./FGA/dns-server-roles.html). JdeBP 6 лет назад 0

1 ответ на вопрос

-1
davidgo

Это все выглядит правильно для меня. CNAME указывает на другое доменное имя - но клиент должен выполнить второй поиск для преобразования возвращенного CNAME в запись A - таким образом, вы не ожидаете, что dig или nslookup вернут IP-адрес.

Спасибо Дэвид, поэтому, когда я копаю с помощью одной и той же команды, единственное, что отличается, это то, что я копаю рекурсивный сервер @working, я получаю правильный ответ с помощью cname и A record `;; РАЗДЕЛ ВОПРОСА:; server1.example1.com. В ;; РАЗДЕЛ ОТВЕТА: server1.example1.com. 592 IN CNAME server1.example2.com. server1.example2.com. 1200 IN A 10.xxx .......... Также nslookup на клиенте возвращает запись, и разрешение работает отлично. Поэтому я считаю, что он должен вернуть запись A клиенту. Спасибо за помощь ryans11 6 лет назад 0
Первый яркий индикатор того, что этот ответ неправильный, заключается в том, что он начинается с обсуждения URL-адресов. DNS не работает с точки зрения URL-адресов, и разрешающий прокси-сервер DNS, как и вопросник, должен выполнять все необходимые внутренние запросы, чтобы получить полный ответ для внешнего интерфейса. Клиентские библиотеки _не_ не должны выполнять несколько запросов переднего плана. JdeBP 6 лет назад 1
@JdeBP Спасибо, что привередлив к ответу, который является правильным, за исключением того, что произнес URL для доменного имени - я его поменяю. Пожалуйста, внимательно прочитайте ответ ryans11 - он подтверждает, что мой ответ был правильным и помог ему! davidgo 6 лет назад 0
@JdeBP - RFC1035 - в разделе 3.3.1 говорится, что «записи CNAME не требуют дополнительной обработки раздела, но в некоторых случаях серверы имен могут перезапустить запрос по каноническому имени. См. Описание логики сервера имен в [RFC-1034] для подробности." davidgo 6 лет назад 0
@JdeBP Кроме того, в разделе 7.2 RFC1035 говорится, что «распознаватель, как правило, имеет только очень четкие подсказки о том, какие серверы запрашивать, в форме NS RR, и, возможно, должен будет пересмотреть запрос в ответ на CNAME или пересмотреть набор имен. серверы, которые запрашивает распознаватель, в ответ на ответы делегирования, указывающие распознавателю на серверы имен ближе к нужной информации. davidgo 6 лет назад 0
Вы просто не понимаете, как работают DNS-серверы. К сожалению, RFC не помогут вам, потому что их легко понять неправильно, так же как вы их неправильно поняли здесь. Эта часть RFC1035 описывает поведение сервера _content_, а не сервера, который выполняет задачу разрешения запросов. Жаргон _name server_ в этих RFC имеет очень конкретное значение, и это не то, что вы думаете. JdeBP 6 лет назад 0
@JdeBP - Ради ясности раздел 2.1 подтверждает, что распознаватель является локальным для устройства конечных пользователей. «С точки зрения пользователя, доменные имена полезны в качестве аргументов для локального агента, называемого распознавателем, который извлекает информацию, связанную с доменное имя." davidgo 6 лет назад 0
@JdeBP - Конечно, нет - я являюсь администратором DNS для интернет-провайдеров более 20 лет, работая как с автономными, так и с рекурсивными DNS. У меня есть только опыт работы с BIND (включая split dns, только рекурсивный, только авторизационный), ProDNS, PureDNS davidgo 6 лет назад 0
Тогда с какой стати вы торгуете ерундой из-за того, что клиенты делают второй поиск, когда вы должны знать лучше? JdeBP 6 лет назад 0
Давайте [продолжим это обсуждение в чате] (https://chat.stackexchange.com/rooms/74117/discussion-between-davidgo-and-jdebp). davidgo 6 лет назад 0
@JdeBP Я не знаю лучше - что, по вашему мнению, означает RFC1035, когда в разделе 7.2 говорится, что резолверам, возможно, придется пересмотреть запрос или пересмотреть набор серверов имен, которые они запрашивают? RFC 1035 не использует термин «контент-сервер» - раздел 7 называется «RESOLVER IMPLEMENTATION» - поэтому трудно поверить, что он ссылается на контент, а не на резольверы. davidgo 6 лет назад 0