VPN-DNS verkeerd? Een gesaghebbende bediener kan verouderd wees
Koppel die VPN en ’n naam los op na gister se adres. Die tonnel het nie DNS gebreek nie; ’n gepubliseerde gesaghebbende bediener het die hele tyd verouderde sone-data gelewer.
Koppel die VPN en een gasheernaam los op na gister se adres, of na niks. Ontkoppel en dit werk weer. Die refleks is om die oplosser te blameer wat die tonnel gestoot het, maar die meer algemene oorsaak is ’n gepubliseerde naamdiener wat opgehou het om sone-opdaterings te ontvang. Die nuwe pad het bloot ’n ander gesaghebbende bediener bereik as die een waarvan jou gekasde antwoord gekom het.
Die simptoom verander saam met die oplosser
’n Rekursiewe oplosser gee terug wat ’n gesaghebbende bediener vir hom gesê het, en hou dan daardie antwoord vir die TTL. As die tonnel ’n ander oplosser stoot, of die pad verander sodat die ou een nie meer bereikbaar is nie, vra die kliënt ’n ander gesaghebbende bediener en kry ’n ander antwoord. Die domein het op daardie oomblik nie verander nie; jou siening daarvan het.
Dit is hoekom dieselfde naam in een kantoor kan werk en uit ’n hotel kan misluk, en hoekom die skoonmaak van ’n plaaslike kas net soms help. Om die kas skoon te maak stuur die vraag weer na dieselfde gesaghebbende bediener.
Die onderskeidende toets is ’n direkte navraag aan elke gepubliseerde bediener.
Vra elke gesaghebbende bediener direk
Begin by die delegasie eerder as by ’n lys wat jy onthou. Vra die ouer vir die NS-stel en vra dan elke naam in daardie stel vir die rekord wat jy nodig het. Twee navrae teen dieselfde naam by verskillende gesaghebbende bedieners sê dadelik vir jou of die sone konsekwent is.
dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A
Doen dieselfde vir die sone-apex NS-rekords, want die ouer-delegasie en die sone se eie NS-stel kan na ’n migrasie verskil. Reeksnommers op die SOA is die volgende ding om te vergelyk, en ’n sekondêre een wat ver agter is, is ’n oordragprobleem eerder as ’n antwoordprobleem.
Voer daardie navrae uit vanaf die netwerk wat misluk, nie net vanaf jou lessenaar nie.
Skei bedoelde sienings van stukkende sienings
Sommige domeine antwoord doelbewus anders per streek of oplosser-groep, en split-horizon-opstellings is normaal in ondernemingsnetwerke.
Die vraag is of die verskil gedokumenteer en stabiel is. ’n Onbedoelde siening lyk anders: een gesaghebbende bediener het ’n rekord wat die ander nooit ontvang het nie, of dit mis een wat hulle almal deel. Die RFC 2182-riglyne vir keuse en ontplooiing beskou gesaghebbende beskikbaarheid as ’n gedeelde verantwoordelikheid, en dit is die regte raamwerk hier. Oortolligheid bestaan net as elke gepubliseerde bediener die bedoelde data kan antwoord, nie bloot ’n verbinding op poort 53 kan aanvaar nie.
’n Bediener wat SERVFAIL antwoord, is makliker om te diagnoseer as een wat selfversekerd en verkeerd antwoord.
’n Migrasie ontbloot wat ’n kas verberg het
Tydens ’n verskuiwing van verskaffer verander twee gesaghebbende plekke: die ouer-delegasie en die sone se eie NS-rekords. Albei moet opgedateer word, en albei word vir hul TTL’s gekas. As ’n ou bediener aanbly en die vorige sone bly bedien, sal kliënte wie se oplossers dit vra, lank nadat die oorskakeling volledig gelyk het, steeds die ou antwoord kry.
Dit is presies die toestand wat ’n langdurige kas verberg. Die werkstasie wat die hele week gewerk het, het met ’n oplosser gepraat wat ’n vars antwoord van die nuwe gesaghebbende bediener gehou het, terwyl die ou een aanhou om verouderde data aan almal anders uit te deel.
Om die oplosser op ’n skootrekenaar te verander, maak daardie skootrekenaar reg en niks anders nie.
Maak die sone reg, nie die oplosser nie
Identifiseer watter bedieners bedoel is om gesaghebbend vir die sone te wees, korrigeer die bestuurde sone of die delegasie sodat elkeen van hulle die bedoelde data lewer, en behou die oortolligheid wat jy beplan het. Om ’n naamdiener te skrap omdat een VPN-uitgang ’n vreemde antwoord gekry het, verminder beskikbaarheid en laat die inkonsekwentheid in plek.
Voer dan die direkte navrae weer uit vanaf albei netwerke en wag die TTL van die rekord wat jy verander het, uit.
Bevestig dat die antwoord van elke gesaghebbende bediener stabiel is, en skryf die bedoelde siening in die sone-dokumentasie sodat die volgende verskil maklik geklassifiseer kan word.