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 запісу, які вы змянілі.

Пераканайцеся, што адказ стабільны з кожнага аўтарытэтнага сервера, і запішыце намернае прадстаўленне ў дакументацыю зоны, каб наступную розніцу было лёгка класіфікаваць.