Грешен DNS през VPN? Един авторитетен сървър може да е остарял

Свържете VPN и едно име се резолвва към адреса от вчера или към нищо. Прекъснете и то отново работи. Рефлексът е да обвиним резолвера, който тунелът е наложил, но по-честата причина е публикуван сървър за имена, който е спрял да получава зонални обновления. Новият път просто е достигнал друг авторитетен сървър, различен от този, от който е дошъл кешираният ви отговор.

Симптомът се променя с резолвера

Рекурсивният резолвер връща това, което авторитетният сървър му е казал, и след това пази отговора за времето на TTL. Ако тунелът наложи друг резолвер или промени пътя така, че старият вече не е достъпен, клиентът пита друг авторитетен сървър и получава друг отговор. Домейнът не се промени в този момент; промени се вашият изглед към него.

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

Разграничаващият тест е директна заявка към всеки публикуван сървър.

Питайте всеки авторитетен сървър директно

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

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

Направете същото за NS записите на върха на зоната, защото родителската делегация и собственият NS набор на зоната може да се разминават след миграция. Серийните номера в SOA са следващото нещо за сравнение, а вторичен сървър, който е много назад, е проблем с трансфера, а не с отговора.

Изпълнете тези заявки от мрежата, която се проваля, а не само от бюрото си.

Отделете предвидените изгледи от счупените

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

Въпросът е дали разликата е документирана и стабилна. Непредвиден изглед изглежда различно: един авторитетен сървър има запис, който останалите никога не са получили, или му липсва такъв, който всички споделят. Насоките на RFC 2182 за избор и внедряване разглеждат авторитетната наличност като споделена отговорност и това е правилната рамка тук. Резервирането съществува само ако всеки публикуван сървър може да отговори с предвидените данни, а не просто да приеме връзка на порт 53.

Сървър, който отговаря SERVFAIL, се диагностицира по-лесно от този, който отговаря уверено и грешно.

Миграцията разкрива какво е скрил кешът

При смяна на доставчик две авторитетни места се променят: родителската делегация и собствените NS записи на зоната. И двете трябва да се обновят и двете се кешират за съответните си TTL. Ако стар сървър остане включен и продължи да обслужва предишната зона, клиентите, чиито резолвери го питат, ще продължат да получават стария отговор дълго след като преминаването е изглеждало завършено.

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

Смяната на резолвера на лаптоп оправя този лаптоп и нищо друго.

Поправете зоната, не резолвера

Определете кои сървъри трябва да са авторитетни за зоната, коригирайте управляваната зона или делегацията, така че всеки от тях да подава предвидените данни, и запазете резервирането, което сте планирали. Изтриването на сървър за имена, защото един изход на VPN е получил странен отговор, намалява наличността и оставя несъответствието на място.

След това изпълнете отново директните заявки от двете мрежи и изчакайте изтичането на TTL на записа, който сте променили.

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