HTTPS- og SVCB-poster – publiser bare det tjenesten støtter

SVCB og HTTPS er DNS-posttyper som beskriver hvordan en klient kan nå en tjeneste. De kan peke til alternative endepunkter og annonsere parametere som ALPN, port og adressehint før den første forbindelsen etableres.

HTTPS er SVCB-varianten for HTTP-opprinnelser. Den har DNS-typekode 65. SVCB har typekode 64 og brukes gjennom egne protokollkartlegginger.

Postene er ikke nødvendige for alle nettsteder. En feil HTTPS-post kan følges av klienter som støtter standarden, mens eldre klienter fortsetter med A og AAAA og ser ut til å virke normalt. Plattformen, ikke gjetting i DNS-panelet, bør derfor være kilden til verdiene.

Hva RFC 9460 løser

RFC 9460 definerer en struktur som kan:

• delegere tjenestetilkoblingen til et annet navn
• beskrive flere endepunkter med prioritet
• annonsere støttede ALPN-protokoller
• oppgi en alternativ port
• gi IPv4- og IPv6-hint
• bære utvidelser som klienten må forstå før posten brukes

Klienten kan få mer informasjon i DNS og unngå enkelte ekstra tilkoblingsforsøk. Gevinsten avhenger av klient, resolver, nettverk og plattform.

Posten erstatter ikke:

• A og AAAA for klienter uten støtte
• TLS-sertifikatet
• serverens HTTP/2- eller HTTP/3-konfigurasjon
• QUIC-tilgang gjennom brannmur
• HTTP-redirect og canonical URL
• CAA, HSTS eller sikkerhetsheadere

Feltene i HTTPS og SVCB

Presentasjonsformatet er:

Name TTL IN HTTPS SvcPriority TargetName SvcParams

Et eksempel i ServiceMode:

bedrift.no. 300 IN HTTPS 1 . alpn="h2,h3"

Punktum som TargetName i ServiceMode betyr at målvertsnavnet er eiernavnet.

AliasMode: prioritet 0

En post med SvcPriority 0 er i AliasMode:

bedrift.no. 3600 IN HTTPS 0 svc.plattform.example.

Dette delegerer HTTPS-tjenestebindingen til målnavnet. AliasMode kan brukes på soneapex uten å bli en CNAME som kolliderer med SOA, NS, MX og TXT.

Forskjellen fra CNAME er viktig:

• HTTPS AliasMode gjelder HTTPS-posttypen og tjenesten
• CNAME gjør hele navnet til alias for ordinære DNS-oppslag
• MX, TXT og andre posttyper på apex påvirkes ikke av HTTPS-aliaset
• eldre klienter som ikke bruker HTTPS-posten trenger fortsatt A/AAAA-veien

Et AliasMode-postsett bør bare ha én aliaspost. Parametere i AliasMode er ikke definert i grunnstandarden og ignoreres av mottakere. Legg parametrene på ServiceMode-posten hos målet.

Unngå kjeder og løkker. Klienter skal ha en grense for hvor mange SVCB-aliaser de følger, og lange kjeder gir kompatibilitets- og ytelsesrisiko.

ServiceMode: positiv prioritet

En positiv SvcPriority betyr ServiceMode:

bedrift.no. 300 IN HTTPS 1 edge-a.plattform.example. alpn="h2,h3"
bedrift.no. 300 IN HTTPS 2 edge-b.plattform.example. alpn="h2"

Klienten foretrekker lavere prioritet blant kompatible poster og kan prøve lavere prioriterte alternativer. Poster med samme prioritet kan velges i tilfeldig rekkefølge.

Dette er ikke i seg selv applikasjonshelse eller garantert failover. DNS-eieren må sikre at endepunktene, parameterne, sertifikatene og dataene faktisk gir samme tjeneste.

De viktigste SvcParam-nøklene

alpn

alpn="h2,h3"

h2 er HTTP/2 over TLS. h3 annonserer HTTP/3 over QUIC. Ikke annonser h3 før UDP, QUIC, TLS og plattformen virker ende til ende. ALPN i DNS avgjør ikke alene hva forbindelsen blir; klient og server forhandler fortsatt protokoll.

no-default-alpn

Denne nøkkelen sier at klienten ikke skal anta standard ALPN. Den er automatisk obligatorisk når den brukes. En post med no-default-alpn uten en brukbar alpn-verdi er feilkonfigurert.

port

port="8443"

Port kan styre klienten til en annen tjenesteport. Brannmur, proxy, TLS og klientpolicy må tillate den. For offentlige nettsteder er 443 enklere og mer kompatibelt; ikke flytt port i DNS uten en dokumentert plattformmodell.

ipv4hint og ipv6hint

ipv4hint="192.0.2.40"
ipv6hint="2001:db8::40"

Hint kan gi klienten adresser tidlig, men erstatter ikke korrekte A- og AAAA-svar. Klienter kan hente og foretrekke de ordinære adressepostene. Utdaterte hint kan svekke lastbalansering, geografisk styring og tilgjengelighet.

RFC 9460 fraråder hint når målet allerede er eiernavnet og de ikke gir forventet ytelsesgevinst. La plattformen generere dem hvis den kan holde dem synkronisert. Eksempeladressene er reservert for dokumentasjon.

mandatory

mandatory="alpn,port" alpn="h3" port="8443"

mandatory lister nøkler klienten må forstå for at ServiceMode-posten skal være kompatibel. Alle listede nøkler må finnes i samme post.

Bruk ikke mandatory som pynt. En klient som ikke kjenner en obligatorisk nøkkel skal ignorere posten. Det er riktig når tjenesten ikke fungerer uten parameteren, men kan redusere kompatibiliteten.

ech

ECH-konfigurasjon kan distribueres i HTTPS/SVCB for klienter som støtter Encrypted ClientHello. Verdien er binær og knyttet til plattformens TLS-oppsett. RFC 9848 beskriver mekanismen.

Ikke konstruer eller kopier ech manuelt mellom domener. Plattformen må generere, rotere og samordne DNS-verdien med ECH-tjenesten.

HTTPS-posten og HTTP/3

En HTTPS-post kan annonsere h3 slik at en støttet klient vet at QUIC er tilgjengelig før den har fått et Alt-Svc-svar over HTTP/2.

Før h3 publiseres, kontroller:

• UDP 443 fra flere nettverk
• TLS-sertifikat for det opprinnelige vertsnavnet
• at proxy eller origin faktisk tilbyr HTTP/3
• fallback til HTTP/2 når UDP blokkeres
• observasjon av protokoll og feilrate hos reelle brukere

TLS-sertifikatet valideres fortsatt mot origin-navnet i URL-en, ikke bare TargetName. Å peke til et leverandørnavn gjør ikke leverandørens sertifikat automatisk gyldig for bedrift.no.

Les HTTP/2 mot HTTP/3 for transportdelen.

Klienter uten støtte trenger fortsatt en vei

Eksisterende HTTP-klienter skal kunne fungere uten ServiceMode. Offentlige tjenester bør derfor normalt beholde korrekte A- og AAAA-poster for authority endpoint eller AliasMode-målet.

Det gir en overgangsrisiko:

• gammel klient bruker A/AAAA og virker
• moderne klient følger HTTPS-posten til et feil mål og feiler
• enkel overvåking tester bare den gamle veien og viser grønt

Test både med og uten HTTPS/SVCB-støtte. Standarden har også sikkerhetsregler for fallback. Når et kryptografisk beskyttet SVCB-oppslag feiler på bestemte måter, kan klienten behandle feilen som fatal for å unngå nedgradering. «Den faller alltid tilbake til A» er derfor for enkelt.

DNSSEC og verktøystøtte

HTTPS/SVCB kan påvirke mål, port og sikkerhetsparametere. Behandle posten med samme integritetskrav som A og AAAA.

dig bedrift.no HTTPS +dnssec
dig bedrift.no A +dnssec
dig bedrift.no AAAA +dnssec

Kontroller at validerende resolvere får gyldige svar. Hvis resolveren eller verktøyet er gammelt, kan typekoden brukes:

dig bedrift.no TYPE65

Et eldre verktøy kan vise generisk wire-data i stedet for lesbare parametere. Det betyr ikke nødvendigvis at posten mangler.

Kryptert DNS-transport som DoH eller DoT beskytter veien mellom klient og resolver. DNSSEC validerer dataenes opprinnelse og integritet gjennom DNS-kjeden. De løser ulike deler av tillitsmodellen.

Cloudflare kan generere HTTPS-poster automatisk

Cloudflare oppgir at proxied poster med Universal SSL og aktiv HTTP/2 eller HTTP/3 kan få HTTPS-poster generert automatisk. Da kan en manuell post kollidere med plattformens edgekonfigurasjon.

Kontroller først:

• om posten er automatisk
• om DNS-posten er proxied eller DNS-only
• hvilke protokoller som er aktivert for sonen
• om den manuelle posten overstyrer eller dupliserer automatikken

Endre gjennom funksjonen som eier posten. Ikke legg inn et statisk h3-signal for å få HTTP/3 hvis edge-tjenesten ikke er aktivert.

Slik tester dere før og etter publisering

1. Dokumenter dagens vei

Ta vare på HTTPS, A, AAAA, CNAME, TTL, DNSSEC-status og proxy-status.

2. Test endepunktene direkte

Kontroller HTTPS mot alle TargetName og adresser med riktig Host/SNI. Test sertifikat, status, innhold og kritiske flyter.

3. Publiser med kontrollert TTL

Bruk leverandørens anbefalte format. Ikke håndskriv ukjente binærverdier eller adressehint.

4. Spør alle autoritative servere

dig @<autoritativ-navnetjener> bedrift.no HTTPS +norecurse
dig @<autoritativ-navnetjener> bedrift.no A +norecurse
dig @<autoritativ-navnetjener> bedrift.no AAAA +norecurse

5. Sammenlign klientveier

Test støttede moderne klienter, en klient uten HTTPS-postbruk og nettverk med blokkert UDP for å bekrefte HTTP/2-fallback.

6. Overvåk resultatet

Mål DNS-feil, TLS-feil, valgt ALPN, QUIC-suksess, responstid og endepunkt. Et vanlig HTTP-up-signal kan skjule at bare ServiceMode-veien feiler.

7. Ha rollback

Ved feil fjernes eller rettes HTTPS/SVCB-posten uten å slette fungerende A, AAAA, MX eller TXT. Følg gjennom gammel TTL og kontroller at plattformens automatikk ikke oppretter posten på nytt.

Vanlige konfigurasjonsfeil

Når bør dere bruke posten?

Bruk HTTPS/SVCB når:

• hosting- eller CDN-leverandøren dokumenterer oppsettet
• tjenesten støtter parameterne ende til ende
• A/AAAA-fallback er planlagt
• dere kan teste relevante klienter og nettverk
• DNSSEC- og automatiseringsmodellen er forstått

Ikke opprett posten bare fordi DNS-panelet tilbyr typen. For en enkel nettside er korrekt A/AAAA eller CNAME, gyldig HTTPS og en rask plattform viktigere enn et manuelt avansert postsett.

Vymo setter opp og hoster én enkel bedriftsnettside i standardleveransen. Kunden får foreløpig ikke et selvbetjent HTTPS/SVCB-, HTTP/3- eller DNSSEC-panel. Hvis DNS ligger hos en annen leverandør, bruk bare verdier den konkrete plattformen har oppgitt. Send domenenavn, DNS-leverandør og den offentlige posten via kontaktsiden . Ikke send passord, API-nøkler, flyttekoder eller private nøkler.

HTTPS/SVCB er best når posten beskriver virkeligheten automatisk. Hvis DNS annonserer protokoll, port eller mål som tjenesten ikke leverer, blir den moderne optimeringen en egen feilvei.