NXDOMAIN през VPN не означава прекъсване на тунела

Изкушаващо е един неуспешен lookup да се прочете като доказателство, че тунелът е рухнал, особено когато името е работело преди десет минути. Отговорът говори друго. NXDOMAIN е завършена DNS транзакция, в която резолверът е заявил, че търсеното име не съществува; счупен тунел обикновено произвежда тишина, таймаут или опит за резолюция към грешен сървър. Версията на аргумента без wireshark е една заявка, един отговарящ и един код на отговор и тази тройка си струва да се запише преди каквито и да е промени в конфигурацията.

Какво всъщност доказва отговорът

DNS разделя резултати, които клиентите често свиват до един провал. Име, което не съществува, дава отрицателен отговор с код NXDOMAIN, докато име, което съществува, но няма запис от търсения тип, дава успешен отговор с празна секция за отговори. И двете изглеждат на приложението като нищо полезно и само едното от тях означава, че името е грешно.

Тази разлика решава къде принадлежи поправката. Липсващ запис AAAA на хост, който има запис A, не е липсващ хост и преиздаването на сертификат или престрояването на тунел, за да го гони, прахосва единствената налична следа. Разграничението определя и формата на продължението: проблем с именуването се поправя в зоната, а проблем с типа се поправя чрез заявка за правилния запис или чрез приемане, че семейството адреси просто липсва.

Митът: липсващо частно име означава, че тунелът е отказал

Митът оцелява, защото двете събития толкова често идват заедно. Клиент се свързва с VPN, операционната система запазва резолвер, на който вече е вярвала, и вътрешното име, което сега му трябва, се пита от сървър, който никога не е чувал за частната зона. Този сървър отговаря честно и отрицателно. Тунелът носи пакета; отговорът е просто за пространство от имена, което отговарящият не обслужва.

Конфигурациите split-horizon правят това рутинно: същото име на зона съществува публично и вътрешно с различно съдържание и само вътрешният резолвер знае частните записи. Затова получаването на отрицателен отговор, който изглежда авторитетен, е доказателство кой резолвер е отговорил, а не доказателство за състоянието на интерфейса.

Две подробности в конфигурацията решават изхода. Тунелът трябва да изпрати или избере вътрешния резолвер и клиентът трябва да приложи този избор към името, което се търси. Правило за отделен домейн, което именува суфикс, малко различен от записа, който сте въвели, ще изпрати заявката по публичния път и отговорът ще бъде правилен и безполезен.

Питайте правилния резолвер с правилното име

Записвайте отговарящия, преди да запишете присъдата. Заявка, която не показва кой сървър е отговорил, не може да различи проблем с политика от проблем с пространство от имена, а двете имат несвързани поправки.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Първите два реда показват какво е решил локалният резолвер и кого ще пита. Заявката +search възпроизвежда това, което прави приложението, когато добави суфикс за търсене, което често е истинската заявка, а не онази, въведена в диагностичен инструмент. Последният ред пита вътрешния сървър директно, заобикаляйки клиентската политика; ако това успее, докато обикновената заявка се проваля, зоната е наред, а маршрутизирането на заявките не е.

Отрицателното кеширане обяснява забавянето след поправка

Отрицателните отговори се кешират по замисъл и RFC 2308 описва как животът на отрицателния кеш се извежда от записа за авторитет на зоната. Затова коригирането на запис или правило на резолвер не гарантира незабавна промяна на клиента, а повторението на заявка, която връща кеширания отговор, не доказва нищо ново. Само различен отговарящ, различно име или изчистен кеш дава свежи доказателства.

Изчистете локалния кеш, после повторете същата заявка към същия отговарящ. На системи с локална услуга за резолвер това е една команда; на други това е рестарт на услуга или платформена помощна програма и конкретният инструмент е по-малко важен от повторението на идентичен тест след това.

Отделете името от пътя

Щом името се резолвне до очаквания частен адрес, DNS като тема приключва и следващият въпрос става пътят на приложението. Хост, който отговаря на заявки, но отказва връзка, има различен проблем и продължаването да се настройват резолвери след правилен отговор е начинът, по който един инцидент се сдобива с три несвързани промени. Сравнете резолвнатия адрес с този, на който услугата всъщност слуша, преди да приемете, че двата съвпадат.

Пазете записа: заявката, отговарящият, кодът и резолвнатият адрес. Този запис е и това, което прави по-късния доклад проверим, и е разликата между диагноза и история за тунел, който е изглеждал бавен.