AAAA-post og IPv6 – publiser bare en testet forbindelse

En AAAA-post kobler et DNS-navn til en IPv6-adresse. Når bedrift.no har både A og AAAA, kan en klient bruke IPv4 eller IPv6 for å nå nettstedet.

AAAA er ikke bare ekstra informasjon for fremtiden. Når posten publiseres, blir IPv6 en produksjonsvei. Server, nettverk, brannmur, HTTPS og overvåking må derfor fungere over IPv6 før DNS ber brukere prøve den.

Slik ser en AAAA-post ut

bedrift.no.  300  IN  AAAA  2001:db8::40

Feltene betyr:

2001:db8::/32 er reservert for dokumentasjon. Ikke bruk eksempeladressen i produksjon. Bruk den stabile adressen hosting-, CDN- eller plattformleverandøren har tildelt den konkrete tjenesten.

RFC 3596 definerer AAAA som en post som lagrer én 128-bits IPv6-adresse. Et navn med flere IPv6-adresser har flere AAAA-poster.

Hvorfor heter posten AAAA?

En IPv4-adresse i en A-post er 32 bits. En IPv6-adresse er 128 bits, altså fire ganger så lang. Navnet AAAA uttrykker historisk denne forskjellen.

IPv6 skrives som grupper med heksadesimale tegn og kolon. Sammenhengende nullgrupper kan forkortes én gang med :::

2001:0db8:0000:0000:0000:0000:0000:0040
2001:db8::40

De to linjene representerer samme eksempeladresse. DNS-panelet kan normalisere skrivemåten etter lagring.

Ikke lim inn:

• en IPv6-adresse med hakeparenteser
• et prefiks med /64
• portnummer
• URL eller vertsnavn
• en link-local-adresse som begynner med fe80

AAAA-verdien skal være én IPv6-adresse. CNAME brukes når verdien skal være et annet DNS-navn.

A og AAAA brukes parallelt

Et dual-stack-navn kan ha begge:

bedrift.no.  A     192.0.2.40
bedrift.no.  AAAA  2001:db8::40

A og AAAA er ikke en hoved- og reservepost. De annonserer to mulige adressefamilier. Klientens nettverk, operativsystem og tilkoblingsalgoritme avgjør hvilken forbindelse som vinner.

RFC 8305 beskriver Happy Eyeballs: klienter kan spørre etter A og AAAA omtrent samtidig, sortere adressene og starte konkurrerende forbindelsesforsøk for å redusere synlig forsinkelse når én vei er dårlig.

Dette er en robusthetsmekanisme hos klienten, ikke en tillatelse til å publisere en ødelagt AAAA-post. Klienter implementerer algoritmer ulikt, noen nettverk har særskilte feil, og enkelte integrasjoner forsøker bare én adressefamilie. Mål IPv4 og IPv6 hver for seg.

Når bør dere publisere AAAA?

Publiser når alle disse punktene er bekreftet:

• leverandøren støtter IPv6 for den konkrete tjenesten
• adressen er stabil eller håndteres av plattformen
• ruting fungerer fra internett til riktig grensesnitt
• brannmur tillater bare nødvendige porter
• webserver eller proxy lytter på IPv6
• riktig nettsted velges for vertsnavnet
• TLS-sertifikat og kjede fungerer
• logger behandler IPv6-adresser korrekt
• ekstern overvåking tester IPv6 separat
• beredskapen kan fjerne eller rette AAAA raskt

Stabil IPv4 med A-post er bedre enn en AAAA-post som annonserer en halvferdig IPv6-bane.

bedrift.no og www er separate navn

AAAA på rotdomenet gjelder ikke automatisk www:

bedrift.no.      AAAA  2001:db8::40
www.bedrift.no.  AAAA  2001:db8::40

www kan i stedet være CNAME til rotdomenet eller til en plattform som selv returnerer A og AAAA. Følg leverandørens oppsett og kontroller begge offentlige navn.

Et wildcardsertifikat eller wildcard-DNS endrer ikke at webserveren må kjenne hvert vertsnavn den skal svare riktig for.

IPv6-brannmur må konfigureres uttrykkelig

En tjeneste kan ha gode IPv4-regler og samtidig være åpen eller blokkert over IPv6. Ikke anta at NAT, sikkerhetsgruppe eller host-brannmur kopierer IPv4-policyen.

Kontroller:

• nettverksbrannmur og skyens sikkerhetsgrupper
• lokal brannmur på serveren
• om port 80 trengs for ACME eller redirect
• port 443 for HTTPS
• administrasjonsporter som ikke skal være offentlige
• load balancer, reverse proxy eller CDN
• at origin ikke eksponeres direkte hvis arkitekturen forutsetter proxy

IPv6 gir mange adresser, men stort adresseområde er ikke en tilgangskontroll. Bruk eksplisitte regler og test dem utenfra.

HTTPS må virke på samme vertsnavn

TLS-sertifikatet validerer normalt domenenavnet, ikke om forbindelsen kom over IPv4 eller IPv6. Samme sertifikat kan derfor brukes for begge veier.

Feil oppstår når IPv6-adressen går til:

• en annen server uten riktig sertifikat
• standardnettstedet hos webhotellet
• en gammel server etter migrering
• en proxy med ufullstendig domenebinding
• en brannmur som slipper gjennom TCP, men ikke riktig tjeneste

Test navn, sertifikatkjede, HTTP-status, redirect og innhold over IPv6. At port 443 svarer er ikke nok.

Test IPv6 før DNS publiseres

Hvis leverandøren tillater direkte test og dere har autorisasjon, kan curl --resolve koble domenenavnet til en valgt adresse lokalt uten å endre offentlig DNS:

curl -6 --resolve 'bedrift.no:443:[2001:db8::40]' https://bedrift.no/

Bytt eksempeladressen med adressen dere har fått. Kommandoen skal kjøres fra et nettverk med fungerende IPv6. Den tester vertsnavn og TLS mot valgt adresse, men ikke offentlig DNS eller alle brukerens nettverk.

Kontroller også:

• forventet HTTP-status og innhold
• sertifikatets domenenavn og kjede
• om redirect bevarer riktig vertsnavn
• store bilder eller svar, ikke bare en liten helsesjekk
• skjema og kritiske integrasjoner
• logger og klient-IP-håndtering

Bruk en ekstern IPv6-probe hvis kontornettet bare har IPv4. Ikke stol på én testmaskin.

Publiser kontrollert

1. Dokumenter dagens DNS

Noter A, AAAA, CNAME, aktive navnetjenere, gammel TTL og eventuell proxy-status. Se spesielt etter en gammel AAAA-post dere ikke visste var aktiv.

2. Senk TTL på forhånd

Ved en planlagt innføring kan dere senke TTL minst én gammel TTL-periode før endringen. Da kan en feilpost trekkes tilbake raskere etter publisering.

3. Legg inn bare navnene som er testet

Publiser ikke AAAA for alle subdomener i en masseendring. Start med det avgrensede navnet og tjenesten som er validert.

4. Kontroller autoritativt svar

dig bedrift.no AAAA +short
dig @ns1.dnsleverandor.example bedrift.no AAAA

Alle autoritative navnetjenere skal publisere samme postsett.

5. Test offentlig tjeneste over begge familier

curl -4 -I https://bedrift.no/
curl -6 -I https://bedrift.no/

Sammenlign status, redirect og relevant innhold. Test også www og kritiske underdomener.

6. Følg separate målinger

Overvåk DNS-svar, tilkobling, TLS, HTTP og responstid for IPv4 og IPv6. Et samlet «up»-signal kan skjule at bare den ene banen virker.

7. Ha en enkel rollback

Hvis IPv6-banen feiler og årsaken ikke kan rettes umiddelbart, fjern eller korriger AAAA-posten. Ikke slett A-posten eller resten av DNS-sonen. Fortsett å overvåke gjennom gammel AAAA-TTL fordi enkelte klienter kan ha cachet adressen.

Når en CDN- eller proxyplattform brukes

En proxied DNS-post kan returnere plattformens IPv6-adresser i stedet for origin-serverens adresse. Det kan gi IPv6 mot besøkende selv om forbindelsen fra proxy til origin bruker IPv4.

Hos Cloudflare vil en proxied A-, AAAA- eller CNAME-post returnere Cloudflare-adresser i offentlige oppslag. En DNS-only AAAA-post viser derimot den faktiske IPv6-adressen i posten. Se proxied mot DNS-only før dere tolker forskjellen mellom kontrollpanel og dig som en feil.

Kontroller to separate forbindelser:

1. klient til proxy over IPv6
2. proxy til origin etter plattformens konfigurasjon

Ikke publiser en direkte AAAA til origin bare for å «få IPv6» hvis det omgår sikkerhets- og trafikkmodellen.

Flere AAAA-poster er ikke automatisk failover

Et navn kan ha flere IPv6-adresser. Klienter kan velge og cache dem forskjellig. Vanlig DNS vet ikke uten videre at én webserver er syk.

Flere AAAA-poster krever samme vurdering som flere A-poster:

• konsistent innhold og konfigurasjon
• helsesjekk og kontrollert trafikkstyring
• forståelse av cache og TTL
• riktig TLS på alle adresser
• logging og overvåking per endepunkt

Bruk plattformens dokumenterte løsning fremfor å behandle flere adresser som en gratis lastbalanserer. Guiden til DNS-failover forklarer hvorfor overgangstiden er mer enn postens TTL.

Vanlige AAAA-feil

Bruk guiden til A-poster for IPv4-delen og vanlige DNS-feil når problemet involverer delegering eller DNSSEC.

AAAA i Vymos leveranse

Vymo kobler domene og aktiverer sikker tilkobling for den enkle bedriftsnettsiden vi setter opp og hoster. Kunden får foreløpig ikke et selvbetjent DNS-, IPv6- eller brannmurpanel i standardtilbudet.

Hvis domenets DNS ligger hos en annen leverandør, skal dere bruke rekordtypen og verdiene som oppgis for den konkrete leveransen. Ikke legg inn en tilfeldig AAAA ved siden av fungerende A eller CNAME. Send domenenavnet og dagens DNS-leverandør uten passord, API-nøkler eller flyttekoder.

IPv6 er klart når hele veien er klar. Publiser AAAA etter at riktig navn, adresse, brannmur, TLS og overvåking er testet – og behold en avgrenset rollback hvis den nye banen ikke fungerer for brukerne.