A-post i DNS – pek domenet til riktig IPv4-adresse
En A-post kobler ett DNS-navn til en IPv4-adresse. Riktig navn, offentlig adresse, TTL og kontroll av både origin og proxy avgjør om endringen virker.
Vymo · · 7 min lesing
En A-post kobler et DNS-navn som bedrift.no eller www.bedrift.no til en IPv4-adresse. Nettleseren bruker adressen for å finne tjenesten som skal motta forbindelsen.
A-posten inneholder bare adressen. Den inneholder ikke https://, portnummer, mappe, omdirigering eller informasjon om hvilken nettside serveren skal vise. Det håndteres av webserver, plattform eller proxy etter at DNS-oppslaget er ferdig.
Slik ser en A-post ut
I en sonefil kan en post se slik ut:
bedrift.no. 300 IN A 192.0.2.80
Feltene betyr:
| Felt | Eksempel | Betydning |
|---|---|---|
| Navn | bedrift.no. | Vertsnavnet posten gjelder |
| TTL | 300 | Hvor lenge svaret kan caches, i sekunder |
| Klasse | IN | Internett |
| Type | A | IPv4-adressepost |
| Verdi | 192.0.2.80 | IPv4-adressen i eksemplet |
192.0.2.80 tilhører et område reservert for dokumentasjon og skal ikke kopieres inn som serveradresse. Bruk den eksakte, offentlige IPv4-adressen hosting- eller plattformleverandøren oppgir.
RFC 1035 definerer A-posten som en 32-bits internettadresse og beskriver at et navn med flere adresser har flere A-poster.
Hva betyr @ i DNS-panelet?
Mange kontrollpaneler viser rotdomenet eller soneapex som @:
Type: A
Navn: @
Verdi: 203.0.113.40
I sonen betyr dette vanligvis bedrift.no, ikke en bokstavelig adresse med krøllalfa. Andre paneler ber om tomt navnefelt eller hele domenenavnet.
Les leverandørens feltforklaring før dere lagrer. Hvis panelet automatisk legger til .bedrift.no, kan innskriving av hele navnet i noen systemer skape noe som ligner bedrift.no.bedrift.no.
bedrift.no og www.bedrift.no er to navn
En A-post på rotdomenet dekker ikke automatisk www:
bedrift.no. A 203.0.113.40
www.bedrift.no. CNAME bedrift.no.
Dette er ett vanlig oppsett. Et annet er å bruke A-poster på begge navn, eller å følge en ekstern plattforms egne verdier.
DNS avgjør bare hvor navnene går. Velg deretter én offentlig hovedadresse og omdiriger den andre med HTTP. Hvis begge viser samme innhold uten redirect, kan dere få unødvendige duplikate URL-er og inkonsistente kanoniske signaler.
Hva kan stå i verdifeltet?
En A-post skal ha en gyldig IPv4-adresse, som fire desimaltall fra 0 til 255:
203.0.113.40
Dette er ikke gyldige A-verdier:
https://bedrift.no
203.0.113.40:443
server.plattform.example
203.0.113.40/kampanje
Bruk CNAME når et subdomene skal peke til et annet vertsnavn. Bruk webserver eller redirecttjeneste når en URL skal sendes til en annen URL.
Offentlig og privat IPv4
Adresser i blant annet disse områdene er laget for private nett:
10.0.0.0/8172.16.0.0/12192.168.0.0/16
De er ikke globalt rutbare på internett. En offentlig DNS-post til 192.168.1.20 gjør derfor ikke en intern webserver tilgjengelig for vanlige besøkende. 127.0.0.1 peker på brukerens egen maskin, ikke på virksomhetens server.
IANA vedlikeholder det offisielle registeret over IPv4-adresser med særskilt bruk . Ikke publiser en privat, loopback-, link-local- eller dokumentasjonsadresse med forventning om et offentlig nettsted.
Intern DNS kan med vilje bruke private adresser for tjenester som bare skal nås gjennom bedriftsnett eller VPN. Da må split-DNS, nettverk og tilgang være dokumentert; dette er en annen leveranse enn et offentlig nettsted.
A-post, AAAA og CNAME
| Type | Verdien er | Bruk |
|---|---|---|
| A | IPv4-adresse | Direkte adresse for IPv4 |
| AAAA | IPv6-adresse | Direkte adresse for IPv6 |
| CNAME | Et annet DNS-navn | Alias som følger det andre navnets adresser |
Et nettsted kan ha både A og AAAA. Da kan klienter velge IPv4 eller IPv6. Begge forbindelsesveiene må levere riktig nettsted og HTTPS; en gammel AAAA-post kan ellers gjøre siden feil bare for brukere med IPv6.
En vanlig CNAME kan ikke brukes på soneapex fordi navnet allerede må ha SOA- og NS-poster. Noen leverandører tilbyr ALIAS, ANAME eller CNAME flattening som plattformfunksjon. Les A-post og CNAME sammenlignet før dere erstatter en adresse med et vertsnavn.
DNS sender ikke hele URL-en
En A-post for bedrift.no gjelder alle stier på dette vertsnavnet:
https://bedrift.no/https://bedrift.no/priser/https://bedrift.no/kontakt/
DNS ser ikke /priser/ eller /kontakt/. Webserveren mottar stien etter at forbindelsen er opprettet og velger riktig innhold eller omdirigering.
Det betyr også at en A-post ikke kan:
- sende bare én mappe til en annen server
- omdirigere HTTP til HTTPS
- velge port 8080
- bevare eller endre URL-parametere
- returnere en 301-status
Slike behov løses i HTTP, reverse proxy, lastbalanserer eller applikasjon.
Flere A-poster på samme navn
DNS kan returnere flere IPv4-adresser:
bedrift.no. A 203.0.113.40
bedrift.no. A 203.0.113.41
Dette er ikke automatisk en komplett lastbalanserings- eller failoverløsning. Resolvere og klienter kan cache svar, velge rekkefølge forskjellig og fortsette å prøve en adresse etter at en server har feilet. DNS-svaret kjenner heller ikke nødvendigvis servernes helsetilstand.
Bruk flere A-poster bare når plattformen dokumenterer modellen. Reell failover trenger helsesjekk, trafikkstyring, konsistent innhold og test av hva som skjer med aktive forbindelser og data. Se hvordan DNS-failover planlegges og øves før flere adresser behandles som reserve.
Når en proxy står foran serveren
Et CDN eller en reverse proxy kan endre hva offentlige DNS-oppslag viser. Hos Cloudflare kan en proxied A-post inneholde origin-adressen i kontrollpanelet, mens et offentlig oppslag returnerer Cloudflares anycast-adresser. Besøkende kobler da til Cloudflare, som kobler videre til origin.
Cloudflares dokumentasjon av proxy-status bekrefter at proxied A-, AAAA- og CNAME-svar viser Cloudflare-adresser, mens DNS-only viser det faktiske DNS-målet.
Dette betyr:
- en forskjell mellom panelverdi og offentlig
digkan være forventet - webserveren må tillate og forstå trafikk fra proxyen
- HTTPS mellom klient og proxy og mellom proxy og origin må konfigureres bevisst
- en DNS-only-post til samme origin kan avsløre adressen selv om hovednavnet er proxied
Les proxied mot DNS-only før dere endrer skyikon eller tilsvarende plattformvalg.
Finn A-posten som faktisk publiseres
Et vanlig oppslag:
dig bedrift.no A +short
Windows:
nslookup -type=A bedrift.no
Finn først aktive navnetjenere:
dig bedrift.no NS +short
Spør deretter en autoritativ navnetjener direkte:
dig @ns1.dnsleverandor.example bedrift.no A
Hvis kontrollpanelet viser ny adresse, men den autoritative serveren viser gammel, kan dere ha redigert feil DNS-leverandør eller ikke publisert endringen. Hvis autoritativt svar er nytt og en rekursiv resolver fortsatt viser gammelt, er cache og gammel TTL en sannsynlig forklaring.
Kontroller også:
dig www.bedrift.no A +short
dig bedrift.no AAAA +short
Et problem med www eller IPv6 løses ikke ved å endre A-posten for rotdomenet på nytt.
Trygg endring av A-post
1. Dokumenter dagens oppsett
Noter aktive navnetjenere, A-, AAAA- og CNAME-svar, gammel TTL, proxy-status og hvilken server som leverer nettstedet. Eksporter hele sonen hvis panelet støtter det, men ikke endre e-postposter bare fordi nettsiden skal flyttes.
2. Klargjør den nye tjenesten
Den nye serveren eller plattformen må kjenne domenenavnet, levere riktig innhold og være klar for HTTPS. Bruk leverandørens forhåndsvisning eller en kontrollert teknisk test før offentlig DNS endres.
En server kan svare på IP-adressen og likevel vise feil nettsted når forespørselen bruker bedrift.no. Virtuell host, domenebinding og sertifikat må testes med riktig navn.
3. Senk TTL på forhånd
Hvis dere ønsker en kortere overgang, senk TTL minst én gammel TTL-periode før flyttingen. Å senke TTL i samme øyeblikk som IP-adressen byttes, fjerner ikke eldre svar som allerede er cachet.
4. Endre riktig navn
Oppdater bare postene leverandøren har spesifisert. Kontroller rotdomene, www og eventuell AAAA separat. Ikke slett MX, SPF, DKIM eller DMARC.
5. Sammenlign autoritative og rekursive svar
Spør alle autoritative navnetjenere og minst to rekursive resolvere. De autoritative serverne skal gi konsistente svar. Rekursive svar kan variere til cache utløper.
6. Test hele nettstedet
Kontroller:
- med og uten
www - HTTP og HTTPS
- sertifikat og omdirigering
- viktige sider, bilder og skjema
- både IPv4 og IPv6 hvis AAAA finnes
- eksterne overvåkingspunkter
7. Behold gammel tjeneste gjennom overgangen
Noen besøkende kan bruke gammel adresse til gammel TTL er utløpt. La den gamle serveren levere konsistent innhold eller en kontrollert overgang i denne perioden.
8. Sett normal TTL tilbake
Når løsningen er stabil, sett TTL til en verdi som passer endringstakt og drift. Permanent svært lav TTL gir ikke i seg selv bedre tilgjengelighet.
Vanlige A-postfeil
| Symptom | Sannsynlig årsak | Første kontroll |
|---|---|---|
| Nettstedet finnes ikke | Manglende eller feil A-post | Autoritativt A-oppslag |
www virker ikke | Eget navn mangler post | A/CNAME for www |
| Bare noen ser gammel side | Cache eller ulike autoritative svar | TTL og alle navnetjenere |
| Noen brukere får feil side | Gammel AAAA eller flere A-adresser | A og AAAA separat |
| IP virker, domenet viser feil innhold | Manglende domene-/virtuell host-binding | Plattformens domeneoppsett |
| HTTPS gir navnefeil | Sertifikatet dekker ikke navnet | Sertifikatets SAN-felt |
| Offentlig IP avviker fra panelet | Proxy er aktiv | Proxy-status og edge-svar |
| E-post stoppet etter webflytting | Hele sonen eller MX ble endret | NS, MX og TXT |
Bruk guiden til vanlige DNS-feil når symptomet ikke kan isoleres til én post.
A-poster i Vymos standardleveranse
Vymo kobler domene og aktiverer sikker tilkobling for den enkle bedriftsnettsiden vi setter opp og hoster. Standardtilbudet gir foreløpig ikke kunden et selvbetjent DNS- eller hostingpanel.
Hvis domenet bruker DNS hos en annen leverandør, må riktig A-, AAAA- eller CNAME-oppsett avklares for den konkrete leveransen. Send domenenavnet og dagens DNS-leverandør , men ikke send passord, API-nøkler eller flyttekoder i skjemaet.
En A-post er enkel når grensen er tydelig: ett DNS-navn får én eller flere IPv4-adresser. Resten – TLS, redirect, port, innhold, proxy og helsesjekk – må løses i tjenesten DNS leder til.
Har bedriften funnet riktig navn?
Sjekk om .no-domenet er ledig. Et .no-domene koster 199,- per år, også ved fornyelse.