Чи завжди пошук + сліди точні?

Коли точність кешу DNS викликає сумніви, це, dig +traceяк правило, рекомендований спосіб визначення авторитетної відповіді для Інтернет-запису DNS. Це здається особливо корисним, коли їх також поєднують із собою +additional, що також показує записи клею.

Іноді, мабуть, виникають розбіжності з цього приводу - деякі люди кажуть, що він покладається на локальний резолютор для пошуку IP-адрес проміжних серверів імен, але вихід команди не свідчить про те, що це відбувається поза початковим списком кореня імена серверів. Здається, логічно припустити, що це не було б так, якщо мета +trace- запуститись на кореневих серверах і простежити свій шлях вниз. (принаймні, якщо у вас є правильний список серверів кореневих імен)

Чи dig +traceсправді використовується локальний резольвер для чого-небудь, що минає кореневі сервери імен?

Це, очевидно, поетапні запитання, але це часто бентежить людей, і я не можу знайти канонічне питання, що висвітлює цю тему.

dig +traceє чудовим інструментом діагностики, але один аспект його дизайну широко не зрозумілий: IP-адреса кожного сервера, на який буде проведено запит, отримується з вашої бібліотеки резолюцій . Це дуже легко помітити і часто стає проблемою лише тоді, коли ваш локальний кеш має неправильну відповідь на кешування серверу імен.

Детальний аналіз

Це простіше розбити за допомогою вибірки результату; Я опущу все, що минуло першої делегації НС.

; <<>> DiG 9.7.3 <<>> +trace +additional serverfault.com                                                                      

;; global options: +cmd
.                   121459  IN      NS      d.root-servers.net.
.                   121459  IN      NS      e.root-servers.net.
.                   121459  IN      NS      f.root-servers.net.
.                   121459  IN      NS      g.root-servers.net.
.                   121459  IN      NS      h.root-servers.net.
.                   121459  IN      NS      i.root-servers.net.
.                   121459  IN      NS      j.root-servers.net.
.                   121459  IN      NS      k.root-servers.net.
.                   121459  IN      NS      l.root-servers.net.
.                   121459  IN      NS      m.root-servers.net.
.                   121459  IN      NS      a.root-servers.net.
.                   121459  IN      NS      b.root-servers.net.
.                   121459  IN      NS      c.root-servers.net.
e.root-servers.net. 354907  IN      A       192.203.230.10
f.root-servers.net. 100300  IN      A       192.5.5.241
f.root-servers.net. 123073  IN      AAAA    2001:500:2f::f
g.root-servers.net. 354527  IN      A       192.112.36.4
h.root-servers.net. 354295  IN      A       128.63.2.53
h.root-servers.net. 108245  IN      AAAA    2001:500:1::803f:235
i.root-servers.net. 355208  IN      A       192.36.148.17
i.root-servers.net. 542090  IN      AAAA    2001:7fe::53
j.root-servers.net. 354526  IN      A       192.58.128.30
j.root-servers.net. 488036  IN      AAAA    2001:503:c27::2:30
k.root-servers.net. 354968  IN      A       193.0.14.129
k.root-servers.net. 431621  IN      AAAA    2001:7fd::1
l.root-servers.net. 354295  IN      A       199.7.83.42
;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

com.                        172800  IN      NS      m.gtld-servers.net.
com.                        172800  IN      NS      k.gtld-servers.net.
com.                        172800  IN      NS      f.gtld-servers.net.
com.                        172800  IN      NS      g.gtld-servers.net.
com.                        172800  IN      NS      b.gtld-servers.net.
com.                        172800  IN      NS      e.gtld-servers.net.
com.                        172800  IN      NS      j.gtld-servers.net.
com.                        172800  IN      NS      c.gtld-servers.net.
com.                        172800  IN      NS      l.gtld-servers.net.
com.                        172800  IN      NS      d.gtld-servers.net.
com.                        172800  IN      NS      i.gtld-servers.net.
com.                        172800  IN      NS      h.gtld-servers.net.
com.                        172800  IN      NS      a.gtld-servers.net.
a.gtld-servers.net. 172800  IN      A       192.5.6.30
a.gtld-servers.net. 172800  IN      AAAA    2001:503:a83e::2:30
b.gtld-servers.net. 172800  IN      A       192.33.14.30
b.gtld-servers.net. 172800  IN      AAAA    2001:503:231d::2:30
c.gtld-servers.net. 172800  IN      A       192.26.92.30
d.gtld-servers.net. 172800  IN      A       192.31.80.30
e.gtld-servers.net. 172800  IN      A       192.12.94.30
f.gtld-servers.net. 172800  IN      A       192.35.51.30
g.gtld-servers.net. 172800  IN      A       192.42.93.30
h.gtld-servers.net. 172800  IN      A       192.54.112.30
i.gtld-servers.net. 172800  IN      A       192.43.172.30
j.gtld-servers.net. 172800  IN      A       192.48.79.30
k.gtld-servers.net. 172800  IN      A       192.52.178.30
l.gtld-servers.net. 172800  IN      A       192.41.162.30
;; Received 505 bytes from 192.203.230.10#53(e.root-servers.net) in 13 ms

• Початковий запит на . IN NS(кореневі сервери імен) потрапляє в локальну роздільну здатність, яка в даному випадку - Comcast. ( 75.75.75.75) Це легко помітити.
• Наступний запит призначений для serverfault.com. IN Aі працює проти e.root-servers.net., випадково вибраний зі списку кореневих серверів імен, який ми щойно отримали. У нього IP-адреса 192.203.230.10, і оскільки ми +additionalввімкнули, схоже, він походить від клею.
• Оскільки він не є авторитетним для serverfault.com, це делегується серверам com.імен TLD.
• Що не очевидно з висновку тут, це те, що digне отримав IP-адресу e.root-servers.net.від клею.

На задньому плані ось що насправді сталося:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
02:03:43.301022 IP 192.0.2.1.59900 > 75.75.75.75.53: 63418 NS? . (17)
02:03:43.327327 IP 75.75.75.75.53 > 192.0.2.1.59900: 63418 13/0/14 NS k.root-servers.net., NS l.root-servers.net., NS m.root-servers.net., NS a.root-servers.net., NS b.root-servers.net., NS c.root-servers.net., NS d.root-servers.net., NS e.root-servers.net., NS f.root-servers.net., NS g.root-servers.net., NS h.root-servers.net., NS i.root-servers.net., NS j.root-servers.net. (512)
02:03:43.333047 IP 192.0.2.1.33120 > 75.75.75.75.53: 41110+ A? e.root-servers.net. (36)
02:03:43.333096 IP 192.0.2.1.33120 > 75.75.75.75.53: 5696+ AAAA? e.root-servers.net. (36)
02:03:43.344301 IP 75.75.75.75.53 > 192.0.2.1.33120: 41110 1/0/0 A 192.203.230.10 (52)
02:03:43.344348 IP 75.75.75.75.53 > 192.0.2.1.33120: 5696 0/1/0 (96)
02:03:43.344723 IP 192.0.2.1.37085 > 192.203.230.10.53: 28583 A? serverfault.com. (33)
02:03:43.423299 IP 192.203.230.10.53 > 192.0.2.1.37085: 28583- 0/13/14 (493)

+traceобдурив і порадився з місцевим рішенням, щоб отримати IP-адресу наступного сервера імен хоп замість консультації з клеєм. Підлий!

Зазвичай це "досить добре" і не спричинить проблем для більшості людей. На жаль, є крайові випадки. Якщо з будь-якої причини ваш кеш-код DNS надає неправильну відповідь для сервера імен, ця модель повністю руйнується.

Приклад реального світу:

• термін дії домену закінчується
• Клей перейменований у серверах перенаправлення імен реєстратора
• неправдиві IP-адреси кешовані для ns1 та ns2.yourdomain.com
• поновлюється домен відновленим клеєм
• будь-які кеші з неправдивими IP-серверами імен продовжують надсилати людей на веб-сайт, який говорить, що домен продається

У наведеному вище випадку +traceбуде запропоновано, що власні сервери імен власників домену є джерелом проблеми, і ви за один дзвінок від неправильного повідомлення клієнту про те, що його сервери неправильно налаштовані. Чи це щось, про що ви можете (або готові) зробити щось інше, але важливо мати правильну інформацію.

dig +trace це чудовий інструмент, але як і будь-який інструмент, ви повинні знати, що він робить, а що не робить, і як усунути проблему вручну, коли виявиться недостатньою.

Редагувати:

Слід також зазначити, що dig +traceне попередить вас про NSзаписи, які вказують на CNAMEпсевдоніми. Це порушення RFC, яке ISC BIND (і, можливо, інші) не намагатиметься виправити. +traceбуде повністю радий прийняти Aзапис, який він отримує від локально налаштованого сервера імен, тоді як якби BIND виконував повну рекурсію, він би відхилив всю зону за допомогою SERVFAIL.

Це може бути складно вирішити, якщо клей присутній; це буде працювати чудово, доки записи NS не будуть оновлені , а потім раптом зламаються. Безглузді делегації завжди порушують рекурсію BIND, коли NSрекорд показує псевдонім.

Іншим способом відстеження роздільної здатності DNS без використання локального резолютора для нічого, крім пошуку кореневих серверів імен, є використання dnsgraph (Повне розкриття: я написав це). Він має інструмент командного рядка та веб-версію, про яку можна знайти примірник за адресою http://ip.seveas.net/dnsgraph/

Приклад для serverfault.com, який наразі має проблему DNS:

Дуже пізно до цього потоку, але я думаю, що частина питання про те, чому dig + trace використовує рекурсивні запити до локальних розв’язувачів, безпосередньо не пояснено, і це пояснення стосується точності результатів dig + trace.

Після первинного рекурсивного запиту для NS-записів кореневої зони, тоді dig може видавати наступні запити місцевим розв'язникам за таких умов:

1. відповідь перенаправлення відсікається через розмір відповіді, що перевищує 512 байт для наступного ітеративного запиту

2. dig вибирає запис NS із розділу AUTHORITY відповіді на адресу, для якого у розділі ДОПОМОГА відсутня відповідна запис A (клей)

Оскільки в копанні є лише доменне ім'я з запису NS, діг повинен вирішити ім'я до IP-адреси шляхом запиту на локальний DNS-сервер. Це першопричина (каламбур призначений, вибачте).

У AndrewB є приклад, який не повністю співзвучний тому, що я щойно описав, у тому, що вибрана NS кореневої зони:

. 121459 IN NS e.root-servers.net.

має відповідний запис A:

e.root-servers.net. 354907 IN A 192.203.230.10

Однак зауважте, що не існує відповідної записи AAAA для e-root, а також немає запису AAAA для деяких інших кореневих серверів.

Також зверніть увагу на розмір відповіді:

;; Received 496 bytes from 75.75.75.75#53(75.75.75.75) in 10 ms

496 байт - це загальний розмір для врізаних відповідей (тобто наступним записом клею було б> 16 байт, що відповідає відповіді понад 512 байт). Іншими словами, у запиті для кореневих записів NS повна АВТОРІЯ та повний ДОПОМОГА (як записи A, так і AAAA) перевищуватимуть 512 байт, тому будь-який запит на основі UDP, який не визначає більший розмір запиту через параметри EDNS0, отримати відповідь, яка відрізана десь у розділі ДОПОМОГА, як показано вищенаведеним слідом (лише f, h, i, j і k мають записи клею A і AAAA).

Відсутність запису AAAA для e.root-servers.net та розмір відповіді на "NS". запит настійно підказує, що наступний рекурсивний запит був виконаний з тієї причини, на яку я стверджую. Можливо, клієнт O / S підтримує IPv6 і віддає перевагу записам AAAA - або чомусь іншому.

Але в будь-якому випадку, прочитавши цю тему, я вивчив явище dig + trace, виконуючи рекурсивні запити, наступні за початковим для root. Відповідність між вибором запису NS без відповідного запису клею A / AAAA і викопуванням, а потім надсиланням рекурсивного запиту для цієї запису до локальної DNS становить 100%, на мій досвід. І справжнє зворотне - я не бачив рекурсивних запитів, коли запис NS, обраний із реферала, має відповідний запис клею.