NXDOMAIN преку VPN не значи прекин на тунелот

Привлечно е едно неуспешно пребарување да се прочита како доказ дека тунелот се урнал, особено кога името работеше пред десет минути. Одговорот вели поинаку. 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 како тема е завршен и следното прашање станува патот на апликацијата. Хост што одговара на пребарувања но одбива врска има друг проблем, и продолжувањето да се дотеруваат резолвери по точен одговор е начинот на кој еден инцидент добива три неповрзани промени. Споредете ја резолвираната адреса со онаа на која службата навистина слуша пред да претпоставите дека двете се совпаѓаат.

Чувајте го записот: барањето, одговорниот, кодот и резолвираната адреса. Тој запис е и она што го прави подоцнежниот извештај проверлив, и тоа е разликата меѓу дијагноза и приказна за тунел што изгледал бавен.