Як я можу вирішити проблеми з DNS десь посеред рекурсії?


13

У мене справді дивна проблема зі своїм 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.

Як я можу налагоджувати цю проблему і знайти сервера імен, що ображають?


7
Дякуємо, що надали ім’я домену. Такі проблеми надзвичайно важко усунути на сервісі Serverfault без цієї інформації.
Андрій Б

@AndrewB о, я знаю. Ласкаво просимо, повірте мені :)
strugee

2
@ Відповідь ЕндрюБ має сенс і здається мені правильною. Перш ніж я прочитав його, я помітив, що ваш невдалий запит використовував сервер імен IPV6, а успішний - IPV4. Часто (не в цьому випадку) це натякає на погану конфігурацію IPV6, і може бути корисним явне використання числових адрес IPV [4/6] серверів імен замість псевдонімів.
Гунтрам Блом підтримує Моніку

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

@GuntramBlohm Ви на щось. strugee.netмає п'ять записів NS, але жоден AAAAклей не записує лише Aзаписи клею. Найгірше те, що ці п'ять Aзаписів клею вказують лише на дві різні IP-адреси. Це здається досить крихким налаштуванням. Навіть якщо це не є першопричиною проблеми, на яку слід звернути увагу, варто пильнувати.
kasperd

Відповіді:


24

Як я можу налагоджувати цю проблему і знайти сервера імен, що ображають?

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 в цьому аналізі була виконана проти правильної назви.
Андрій Б

5

Хоча ви справді бачите, що авторитетні сервери імен реагують правильно, вам потрібно стежити за всією ланцюжком роздільної здатності 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. Якщо вторинний працює, просто перемкніть замовлення на вирішувачі та спробуйте ще раз.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.