Glue records – finn og flytt navnetjenerens IP trygt

Hvis ns1.bedrift.no er navnetjener for bedrift.no, oppstår en sirkel: Resolveren må spørre ns1.bedrift.no for å finne sonen, men må først finne IP-adressen til ns1.bedrift.no.

Glue records bryter sirkelen. Foreldresonen .no sender A- og eventuelle AAAA-adresser sammen med NS-henvisningen, slik at resolveren kan nå navnetjeneren og fortsette oppslaget.

Glue er adresseinformasjon i en delegering

Et forenklet svar fra foreldresonen kan se slik ut:

bedrift.no.      86400 IN NS ns1.bedrift.no.
bedrift.no.      86400 IN NS ns2.bedrift.no.
ns1.bedrift.no.  86400 IN A  192.0.2.53
ns2.bedrift.no.  86400 IN A  198.51.100.53

NS-postene ligger i authority-delen av henvisningen. Glue-adressene følger normalt i additional-delen. Eksempeladressene er reservert for dokumentasjon og skal ikke brukes i produksjon.

Glue er ikke en egen DNS-posttype. Adressene uttrykkes som A eller AAAA, men rollen deres bestemmes av at de følger delegeringen fra foreldresonen. I dag er A og AAAA de definerte typene glue.

Hvorfor en vanlig A-post ikke er nok

Barnesonen bør også publisere autoritative adresser:

ns1.bedrift.no.  3600 IN A 192.0.2.53
ns2.bedrift.no.  3600 IN A 198.51.100.53

Men resolveren trenger en startadresse før den kan spørre barnesonen. Derfor finnes samme adresseinformasjon i to administrative lag:

Å endre bare A-posten i barnesonen oppdaterer ikke parent glue. Å endre bare host-adressen gjennom registraren gjør heller ikke automatisk barnesonens A/AAAA riktig.

In-domain, sibling og ekstern navnetjener

Om glue trengs, avhenger av forholdet mellom delegeringen og navnetjenerens navn.

In-domain: nødvendig for å bryte sirkelen

bedrift.no. IN NS ns1.bedrift.no.

Navnetjeneren ligger under domenet den betjener. Resolveren trenger glue fra .no for å finne adressen.

Sibling: under samme forelder, men ikke under delegasjonen

butikk.bedrift.no. IN NS ns1.drift.bedrift.no.

Her delegerer bedrift.no sonen butikk.bedrift.no, mens navnetjeneren ligger under søskendelen drift.bedrift.no. Resolveren kan ofte slå opp adressen gjennom søskensonen, men glue kan følge som optimalisering. Sykliske avhengigheter mellom søskensoner kan likevel skape feil.

Ekstern: adressen finnes gjennom en annen sone

bedrift.no. IN NS ns1.dnsleverandor.example.

Navnetjeneren ligger utenfor bedrift.no og .no. Resolveren finner adressen via dnsleverandor.example. bedrift.no skal ikke ha egen parent glue for denne adressen.

RFC 9471 bruker begrepene in-domain og sibling for å presisere hvilke glue-adresser en parent skal sende i en referral. Tilgjengelig glue for in-domain-navnetjenere skal følge svaret; hvis alt ikke får plass, skal svaret markeres som trunkert slik at klienten kan prøve en annen transport.

Glue er ikke autoritativt svar for navnetjenernavnet

Parent glue er bootstrapinformasjon. Foreldresonen er autoritativ for delegeringen den publiserer, men ikke for de ordinære adressepostene inne i barnesonen.

Hvis parent glue og barnesonens A/AAAA avviker, kan oppførselen variere:

• en resolver kan bruke glue for å nå navnetjeneren
• en resolver kan senere hente den autoritative adressen fra barnesonen
• cache kan holde gammel parent- eller child-informasjon
• én adresse kan fungere mens en annen feiler

Resultatet blir ofte periodiske feil som er vanskeligere å se enn en total nedetid. Verdiene skal derfor holdes konsistente, og gammel tjeneste må leve gjennom overgangen.

Slik ser du glue fra foreldresonen

Et vanlig rekursivt A-oppslag viser ikke nødvendigvis hvor adressen kom fra. Følg delegeringen:

dig +trace bedrift.no NS

Se etter NS for bedrift.no og A/AAAA i additional-delen av svaret fra .no.

Du kan også finne en autoritativ navnetjener for .no og spørre den direkte:

dig no NS +short
dig @<navnetjener-for-no> bedrift.no NS +norecurse

Bytt plassholderen med ett av navnene fra første oppslag. Kontroller hele svaret, ikke bare +short, fordi glue normalt ligger i additional-delen.

For et annet nivå i hierarkiet må du spørre den aktuelle foreldresonen. Glue for butikk.bedrift.no ligger eventuelt i bedrift.no, ikke i .no.

Sammenlign med barnesonens autoritative adresse

Spør navnetjeneren på den konkrete IP-adressen du vil teste:

dig @192.0.2.53 ns1.bedrift.no A +norecurse
dig @192.0.2.53 bedrift.no SOA +norecurse
dig @192.0.2.53 bedrift.no NS +norecurse

Dette skiller tre forhold:

1. IP-adressen er tilgjengelig på DNS-porten.
2. Serveren svarer autoritativt for bedrift.no.
3. Barnesonen publiserer forventet adresse og NS-sett.

Gjenta for IPv4 og IPv6, alle navnetjenere og både UDP og TCP. En DNS-tjeneste som bare virker på én transport eller én registrert adresse oppfyller ikke en robust delegering.

Krav som er særlig relevante for .no

Norid tester navnetjenerne ved registrering og oppdatering. De tekniske kravene til navnetjenere omfatter blant annet:

• minst to navnetjenere på fysisk separate maskiner
• autoritative og konsistente svar
• permanent tilkobling og fast IPv4-adresse
• fast IPv6-adresse hvis IPv6 brukes
• kanoniske navn, ikke CNAME, som NS-mål
• samme SOA-serial hos de oppgitte navnetjenerne

Ved host update for en navnetjener med glue kontrollerer Norid at registrerte IPv4- og IPv6-adresser samsvarer med A- og AAAA-svarene fra navnetjeneren. Minst én IPv4-adresse må være registrert for en slik .no-navnetjener.

Dette betyr at en tilfeldig kontrollpanelendring ikke er nok. Registrarens host-oppdatering og den operative DNS-tjenesten må planlegges som én endring.

IP-bytte uten et dødt mellomrom

Den nøyaktige EPP-rekkefølgen må bekreftes med registraren, fordi registerregler og validering varierer. En robust teknisk plan er:

1. Kartlegg avhengighetene

Finn alle domener og soner som bruker navnetjenernavnet. Ett host-objekt kan være navnetjener for mange kundedomener. En adresseendring kan derfor ha langt større rekkevidde enn domenet navnet ligger under.

2. Start tjenesten på ny adresse

Den nye IP-adressen skal svare autoritativt med samme sonedata før den annonseres. Test:

• UDP og TCP på port 53
• SOA og NS for alle soner
• samme serial og relevante postsett
• IPv4 og IPv6 hver for seg
• DNSSEC-signaturer der det brukes
• overvåking fra eksternt nettverk

3. Lag en overlappsperiode

Hold gammel og ny adresse operative samtidig. For en planlagt tilleggsmigrering kan barnesonen publisere begge adressene før registraren sender en host-oppdatering med det samme nye settet, dersom registrarens prosedyre støtter dette.

Ikke slå av den gamle IP-adressen etter at kontrollpanelet viser ny verdi. Parent glue og resolver-cache har egne TTL-er.

4. Oppdater gjennom registraren

Glue for et .no-domene endres gjennom domeneforhandleren, som sender host-oppdateringen til Norid. Be om bekreftelse på hvilke adresser registeret har akseptert, ikke bare hva som er skrevet i et lokalt skjema.

5. Kontroller parent og child på nytt

Bruk direkte oppslag mot .no, alle autoritative servere og eksterne resolvere. Verifiser at:

• referral inneholder forventede adresser
• A/AAAA i barnesonen matcher
• alle IP-er svarer autoritativt
• gamle og nye sonedata er like
• ingen DNSSEC-kjede ble brutt

6. Fjern gammel adresse kontrollert

Hold den gamle serveren tilgjengelig mens du koordinerer barnesvar og ny host-oppdatering med registraren. Vent deretter gjennom relevante parent- og resolver-cacher før den gamle tjenesten avvikles.

Dokumenter rollback før endringen. Hvis ny adresse feiler, skal gammel server fortsatt kunne bære trafikken mens parent og child rettes.

IPv6-glue krever en full IPv6-tjeneste

En AAAA-adresse i glue gjør IPv6 til en vei til den autoritative DNS-tjenesten. Ikke registrer IPv6 bare fordi serveren har fått en adresse.

Kontroller at:

• global ruting virker begge veier
• nettverks- og host-brannmur tillater UDP og TCP 53
• DNS-programvaren lytter på adressen
• svar med DNSSEC og store postsett virker over TCP
• ekstern overvåking bruker ekte IPv6
• AAAA i barnesonen matcher registrert glue

Feil IPv6 på én navnetjener kan skape forsinkelse eller sporadiske feil selv om IPv4 og den andre serveren fungerer.

Vanlige glue-feil

Glue gir ikke redundans alene

To NS-navn og to glue-adresser hjelper ikke hvis begge peker til samme maskin, samme nettverk eller samme feilkonfigurasjon. Glue løser bare adresseoppdagelsen.

Reell robusthet krever separate navnetjenere, konsistente soner, overvåking, fungerende UDP/TCP, kontrollert tilgang og en plan for å endre adresser uten å miste autoriteten.

Vymos standardleveranse for en enkel bedriftsnettside inkluderer ikke et selvbetjent autoritativt DNS-oppsett eller private navnetjenere. Hvis domenet allerede bruker ns1.dittdomene.no, send domenenavn, navnetjenernavn og planlagt endring via kontaktsiden . Ikke send passord, API-nøkler, flyttekoder eller DNSSEC-private nøkler.

Glue er lite synlig, men svært operativt: Forelderen må vise resolveren til en adresse som faktisk svarer, og barnesonen må bekrefte samme navnetjener. Test begge lag før gammel IP tas bort.