VPN арқылы DNS қате ме? Бір өкілетті сервер ескірген болуы мүмкін
VPN қосыңыз, сонда бір атау кешегі мекенжайға шешіледі. Туннель DNS-ті бұзған жоқ; жарияланған өкілетті сервер басынан бері ескірген аймақ деректерін ұсынып келді.
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-дағы реттік нөмірлер — салыстыратын келесі нәрсе, ал қатты артта қалған қосалқы сервер — беру мәселесі, жауап мәселесі емес.
Бұл сұраныстарды тек өз үстеліңізден емес, істен шыққан желіден орындаңыз.
Көзделген көріністерді бүлінгендерден ажыратыңыз
Кейбір домендер аймаққа немесе шешушілер тобына қарай әдейі өзгеше жауап береді, ал бөлінген көкжиек конфигурациялары кәсіпорын желілерінде қалыпты.
Мәселе — айырмашылық құжатталған және тұрақты ма. Көзделмеген көрініс басқаша көрінеді: бір өкілеттікте қалғандары ешқашан алмаған жазба бар, немесе бәрі бөлісетін жазба оған жетіспейді. RFC 2182 таңдау және орналастыру нұсқаулығы өкілетті қолжетімділікті ортақ жауапкершілік деп қарайды, және бұл осында дұрыс шеңбер. Резервтеу тек әрбір жарияланған сервер көзделген деректермен жауап бере алса ғана бар, тек 53 портында қосылымды қабылдау ғана емес.
SERVFAIL деп жауап берген серверді сенімді және қате жауап бергеннен гөрі диагностикалау оңайырақ.
Көшіру кэш жасырған нәрсені әшкерелейді
Провайдерді ауыстыру кезінде екі өкілетті орын өзгереді: ата-аналық делегация және аймақтың өз NS жазбалары. Екеуін де жаңарту керек, және екеуі де өз TTL-деріне дейін кэштеледі. Егер ескі сервер қосылып тұрып, бұрынғы аймақты ұсынуды жалғастырса, одан сұрайтын шешушілері бар клиенттер ауысу аяқталғандай көрінгеннен көп кейін де ескі жауапты ала береді.
Ұзақ өмір сүретін кэш жасыратын күй — дәл осы. Апта бойы жұмыс істеген жұмыс станциясы жаңа өкілеттіктің жаңа жауабын ұстаған шешушімен сөйлесіп жатты, ал ескісі қалғандардың бәріне ескірген деректерді тарата берді.
Ноутбукте шешушіні ауыстыру сол ноутбукті ғана түзетеді, басқа ештеңені.
Аймақты түзетіңіз, шешушіні емес
Қай серверлер аймақ үшін өкілетті болуы керегін анықтаңыз, басқарылатын аймақты немесе делегацияны олардың әрқайсысы көзделген деректерді ұсынатындай түзетіңіз және жоспарлаған резервтеуді сақтаңыз. Бір VPN шығысы оғаш жауап алды деп атау серверін жою қолжетімділікті азайтады және сәйкессіздікті орнында қалдырады.
Содан кейін тікелей сұраныстарды екі желіден де қайта орындаңыз және өзгерткен жазбаңыздың TTL-і біткенше күтіңіз.
Жауаптың әр өкілеттіктен тұрақты екеніне көз жеткізіңіз және көзделген көріністі аймақ құжаттамасына жазыңыз, сонда келесі айырмашылықты оңай жіктеуге болады.