Как я могу решить проблемы DNS где-то в середине рекурсии?

У меня действительно странная проблема с моим DNS. Мое доменное имя ( strugee.net) неразрешимо в одних сетях и разрешено в других.

Например, в моей домашней сети (в той же сети, где работает сервер):

% dig strugee.net

; <<>> DiG 9.10.3-P4 <<>> strugee.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10086
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;strugee.net.           IN  A

;; ANSWER SECTION:
strugee.net.        1800    IN  A   216.160.72.225

;; Query time: 186 msec
;; SERVER: 205.171.3.65#53(205.171.3.65)
;; WHEN: Sat Apr 16 15:42:36 PDT 2016
;; MSG SIZE  rcvd: 56

Тем не менее, если я войду на сервер в Digital Ocean, домен не сможет решить:

% dig strugee.net      

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> strugee.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58551
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;strugee.net.           IN  A

;; Query time: 110 msec
;; SERVER: 2001:4860:4860::8844#53(2001:4860:4860::8844)
;; WHEN: Sat Apr 16 18:44:25 EDT 2016
;; MSG SIZE  rcvd: 40

Но обращение к авторитетным серверам имен работает просто отлично:

% dig @dns1.registrar-servers.com strugee.net   

; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> @dns1.registrar-servers.com strugee.net
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30856
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;strugee.net.           IN  A

;; ANSWER SECTION:
strugee.net.        1800    IN  A   216.160.72.225

;; AUTHORITY SECTION:
strugee.net.        1800    IN  NS  dns3.registrar-servers.com.
strugee.net.        1800    IN  NS  dns4.registrar-servers.com.
strugee.net.        1800    IN  NS  dns2.registrar-servers.com.
strugee.net.        1800    IN  NS  dns1.registrar-servers.com.
strugee.net.        1800    IN  NS  dns5.registrar-servers.com.

;; Query time: 3 msec
;; SERVER: 216.87.155.33#53(216.87.155.33)
;; WHEN: Sat Apr 16 18:46:36 EDT 2016
;; MSG SIZE  rcvd: 172

Ясно, что где-то есть проблема с большой сетью, которая не может разрешить мой домен, но я не могу понять, где. Я просмотрел digсправочную страницу, чтобы найти варианты, которые могли бы помочь, но не нашел ничего особенно полезного.

Я нахожусь на Namecheap как регистратор доменов, а также хостинг DNS. У меня включена опция DNSSEC. В последнее время я не вносил никаких изменений в настройки DNS.

Как я могу отладить эту проблему и найти оскорбительный сервер имен?

domain-name-system recursive

— strugee
источник

Спасибо за предоставленное имя домена. Подобные проблемы чрезвычайно трудно устранить с помощью Serverfault без этой информации.

— Андрей B

@ AndrewB О, я знаю.

— Пожалуйста

Ответ @ AndrewB имеет смысл и кажется мне правильным. Прежде чем я прочитал его, я заметил, что ваш неудачный запрос использовал сервер имен IPV6, в то время как успешные использовали IPV4. Зачастую (в данном случае, конечно, не в этом случае) это намекает на неправильную конфигурацию IPV6, и может быть полезно явно использовать числовые адреса IPV [4/6] серверов имен вместо псевдонимов.

— Гунтрам Блом поддерживает Монику

@Guntram До тех пор, пока мы помним, что получили ответ от сервера имен, это означает, что мы, по крайней мере, имеем подключение к DNS-серверу. Просто хочу убедиться, что люди не уйдут от этого с неправильным впечатлением ... SERVFAILможет указывать на проблему в восходящем направлении, но это все же указывает на пакет ответа.

— Андрей B

@GuntramBlohm Вы на что-то. strugee.netимеет пять записей NS, но никаких AAAAзаписей о Aклее, только записи о клее. Хуже всего то, что эти пять Aклейких записей указывают только на два разных IP-адреса. Это выглядит как довольно хрупкая установка. Даже если это не является основной причиной проблемы, на это стоит обратить внимание.

— Касперд

Ответы:

Как я могу отладить эту проблему и найти оскорбительный сервер имен?

daxd5 предложил хороший стартовый совет, но единственный реальный ответ здесь заключается в том, что вам нужно знать, как думать, как рекурсивный DNS-сервер. Поскольку на авторитетном уровне существует множество неверных конфигураций, которые могут привести к непоследовательности SERVFAIL, вам необходимы профессиональные средства проверки DNS или инструменты онлайн-проверки.

В любом случае, цель не состоит в том, чтобы помочь вам, но я хотел убедиться, что вы понимаете, что нет окончательного ответа на этот вопрос.

В вашем конкретном случае я заметил, что strugee.netэто зона, подписанная DNSSEC. Это видно из присутствия DSи RRSIGзаписей в справочной цепи:

# dig +trace +additional strugee.net
<snip>
strugee.net.            172800  IN      NS      dns2.registrar-servers.com.
strugee.net.            172800  IN      NS      dns1.registrar-servers.com.
strugee.net.            172800  IN      NS      dns3.registrar-servers.com.
strugee.net.            172800  IN      NS      dns4.registrar-servers.com.
strugee.net.            172800  IN      NS      dns5.registrar-servers.com.
strugee.net.            86400   IN      DS      16517 8 1 B08CDBF73B89CCEB2FD3280087D880F062A454C2
strugee.net.            86400   IN      RRSIG   DS 8 2 86400 20160423051619 20160416040619 50762 net. w76PbsjxgmKAIzJmklqKN2rofq1e+TfzorN+LBQVO4+1Qs9Gadu1OrPf XXgt/AmelameSMkEOQTVqzriGSB21azTjY/lLXBa553C7fSgNNaEXVaZ xyQ1W/K5OALXzkDLmjcljyEt4GLfcA+M3VsQyuWI4tJOng184rGuVvJO RuI=
dns2.registrar-servers.com. 172800 IN   A       216.87.152.33
dns1.registrar-servers.com. 172800 IN   A       216.87.155.33
dns3.registrar-servers.com. 172800 IN   A       216.87.155.33
dns4.registrar-servers.com. 172800 IN   A       216.87.152.33
dns5.registrar-servers.com. 172800 IN   A       216.87.155.33
;; Received 435 bytes from 192.41.162.30#53(l.gtld-servers.net) in 30 ms

Прежде чем идти дальше, нам нужно проверить, действительно ли подпись действительна. DNSViz - это инструмент, часто используемый для этой цели, и он подтверждает, что проблемы действительно есть . Злой красный цвет на картинке говорит о том, что у вас есть проблема, но вместо того, чтобы наводить взгляд на все, мы можем просто развернуть Уведомления на левой боковой панели:

RRSIG strugee.net/A alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/DNSKEY alg 8, id 16517: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/DNSKEY alg 8, id 16517: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/MX alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/NS alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/SOA alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
RRSIG strugee.net/TXT alg 8, id 10636: The Signature Expiration field of the RRSIG RR (2016-04-14 00:00:00+00:00) is 2 days in the past.
net to strugee.net: No valid RRSIGs made by a key corresponding to a DS RR were found covering the DNSKEY RRset, resulting in no secure entry point (SEP) into the zone. (216.87.152.33, 216.87.155.33, UDP_0_EDNS0_32768_4096)

Проблема ясна: срок действия подписи в вашей зоне истек, а ключи необходимо обновить. Причина, по которой вы видите противоречивые результаты, заключается в том, что не на всех рекурсивных серверах включена проверка DNSSEC. Одни, которые проверяют, отбрасывают ваш домен, а для тех, кто этого не делает, это обычный бизнес.

Редактировать: DNS-инфраструктура Comcast, как известно, реализует проверку DNSSEC, и как один из их клиентов я могу подтвердить, что я также вижу SERVFAIL.

$ dig @75.75.75.75 strugee.net | grep status
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2011

— Андрей Б
источник

Ой, у меня был stugee.netв выводе раскопок, который, очевидно, является опечаткой. DNSSEC часть этого анализа была сделана против правильного имени.

— Андрей B

В то время как вы действительно видите, что авторитетные серверы имен отвечают правильно, вам необходимо проследить всю цепочку разрешения DNS. Это, пройдитесь по всей иерархии DNS от корневых серверов вверх.

$ dig net NS
;; ANSWER SECTION:
net.            172800  IN  NS  c.gtld-servers.net.
net.            172800  IN  NS  f.gtld-servers.net.
net.            172800  IN  NS  k.gtld-servers.net.
;; snipped extra servers given
$ dig @c.gtld-servers.net strugee.net NS
;; AUTHORITY SECTION:
strugee.net.        172800  IN  NS  dns2.registrar-servers.com.
strugee.net.        172800  IN  NS  dns1.registrar-servers.com.
;; snipped extra servers again

Это в основном проверяет, работают ли публичные DNS-серверы, и вы делаете то же самое, что должен делать ваш DNS-преобразователь. Таким образом, вы должны получать те же ответы, что и выше, на вашем сервере Digital Ocean, если что-то не так с их распознавателем DNS:

$ dig net NS
$ dig strugee.net NS
$ dig strugee.net

Если первые два запроса терпят неудачу, это сбой DNS на стороне Digital Ocean. Проверьте /etc/resolv.confи попробуйте запросить дополнительный DNS-сервер. Если вторичный работает, просто переключите порядок для резольверов и попробуйте снова.

— daxd5
источник