formatet for en zonefil er defineret i RFC 1035 (afsnit 5) og RFC 1034 (afsnit 3.6.1). Dette format blev oprindeligt anvendt af softwarepakken Berkeley Internet Name Domain (BIND), men er i vid udstrækning blevet overtaget af anden DNS-server-software – selv om nogle af dem (f.eks. NSD, PowerDNS) kun bruger zonefilerne som udgangspunkt for at kompilere dem til databaseformat, se også Microsoft DNS med Active Directory-databaseintegration.
En zonefil er en sekvens af linjeorienterede poster, som hver især er enten et direktiv eller en tekstbeskrivelse, der definerer en enkelt ressourcepost (RR). En post består af felter, der er adskilt af en hvilken som helst kombination af hvidt mellemrum (tabulatorer og mellemrum), og slutter ved en linjegrænse, undtagen inden for en anførselstegn i en strengfeltværdi eller et par omsluttende formateringsparenteser. Enhver linje kan afsluttes med kommentartekst med et semikolon foran, og filen kan også indeholde et vilkårligt antal tomme linjer.
Enheder kan forekomme i vilkårlig rækkefølge i en zonefil, med visse undtagelser.
Direktiver er kontrolelementer, der påvirker resten af zonefilen. Det første felt i et direktiv består af et dollartegn efterfulgt af et nøgleord:
- $ORIGIN efterfølges af et domænenavn, der skal bruges som oprindelse for efterfølgende relative domænenavne.
- $INCLUDE efterfølges af et filnavn og et valgfrit oprindelsesdomænenavn, der skal bruges ved fortolkning af indholdet (som behandles som om det optrådte i den overordnede fil, efterfulgt af en nulstilling til oprindelsesværdien, der går forud for evalueringen af direktivet).
- $TTL, defineret i RFC 2308 (afsnit 4), efterfølges af et tal, der skal anvendes som standard-TTL (time-to-live).
- $GENERATE, en ikke-standardudvidelse, der accepteres af BIND og visse andre navneserverprogrammer til at indsætte flere ressourceposter med én post, efterfølges af en kortfattet repræsentation af en stigende sekvens af ikke-negative tal og derefter en RR-skabelonpost. Der tilføjes en ressourcepost for hvert tal i sekvensen ved hjælp af skabelonen, hvor uhætte “$”-tegn erstattes af tallet.
En ressourcepostindgang består af flere felter som følger (begge feltordner er acceptable og kan anvendes i flæng):
| navn | ttl | registreringsklasse | registreringstype | registreringstype | registreringsdata |
| navn | registreringsklasse | ttl | registreringstype | registreringsdata |
Navnefeltet kan efterlades tomt. Hvis det er tilfældet, arver posten feltet fra den foregående post. Et fritstående @ bruges til at angive den aktuelle oprindelse.
Feltet ttl angiver det antal sekunder, hvorefter en cachingklient skal kassere posten og udføre en ny opløsningsoperation for at få nye oplysninger. Nogle navneservere, herunder BIND, tillader ikke-standardiserede repræsentationer, der anvender forkortelser for tidsenheder (f.eks. “2d”, der betyder to 24-timers dage, eller “1h30m”, der betyder en time og 30 minutter). Det kan udelades, og i så fald vil den resulterende værdi blive fastsat ud fra standard TTL (hvis den er defineret) eller ud fra den foregående post.
Feltet record class angiver recordoplysningernes namespace. Det kan udelades, i hvilket tilfælde den resulterende værdi vil blive fastsat ud fra den foregående post. Det mest almindeligt anvendte navnerum er Internet, angivet ved parameter IN, men der findes og anvendes også andre, f.eks. CHAOS.
Feltet record type er en forkortelse for den type information, der er gemt i det sidste felt, record data. F.eks.: en adressepost (type A for IPv4 eller type AAAA for IPv6) kortlægger domænenavnet fra det første felt til en IP-adresse i postdataene; en postudvekslingspost (type MX) angiver SMTP-mailværten (Simple Mail Transfer Protocol) for et domæne.
Postdatafeltet kan bestå af et eller flere informationselementer, afhængigt af kravene for hver posttype. En adressepost kræver f.eks. kun en adresse, mens en postudvekslerpost kræver en prioritet og et domænenavn. Sådanne informationselementer repræsenteres som felter adskilt af hvidt mellemrum.
EksempelfilRediger
Et eksempel på en zonefil for domænet example.com er følgende:
$ORIGIN example.com. ; designates the start of this zone file in the namespace$TTL 3600 ; default expiration time (in seconds) of all RRs without their own TTL valueexample.com. IN SOA ns.example.com. username.example.com. ( 2020091025 7200 3600 1209600 3600 )example.com. IN NS ns ; ns.example.com is a nameserver for example.comexample.com. IN NS ns.somewhere.example. ; ns.somewhere.example is a backup nameserver for example.comexample.com. IN MX 10 mail.example.com. ; mail.example.com is the mailserver for example.com@ IN MX 20 mail2.example.com. ; equivalent to above line, "@" represents zone origin@ IN MX 50 mail3 ; equivalent to above line, but using a relative host nameexample.com. IN A 192.0.2.1 ; IPv4 address for example.com IN AAAA 2001:db8:10::1 ; IPv6 address for example.comns IN A 192.0.2.2 ; IPv4 address for ns.example.com IN AAAA 2001:db8:10::2 ; IPv6 address for ns.example.comwww IN CNAME example.com. ; www.example.com is an alias for example.comwwwtest IN CNAME www ; wwwtest.example.com is another alias for www.example.commail IN A 192.0.2.3 ; IPv4 address for mail.example.commail2 IN A 192.0.2.4 ; IPv4 address for mail2.example.commail3 IN A 192.0.2.5 ; IPv4 address for mail3.example.com
Zonefilen skal som minimum angive SOA-posten (Start of Authority) med navnet på den autoritative master-navneserver for zonen og e-mail-adressen på den person, der er ansvarlig for forvaltningen af navneserveren (repræsenteret som et domænenavn med et punktum i stedet for det sædvanlige @-symbol). Parametrene i SOA-posten angiver også en liste over tids- og udløbs parametre (serienummer, slaveopdateringsperiode, slaveforsøgstid, slaveudløbstid og den maksimale tid til cache af posten). Nogle navneservere, herunder BIND, kræver også mindst én ekstra NS-post.
I zonefilen er domænenavne, der slutter med et punktum (f.eks. “example.com.” i ovenstående eksempel) fuldt kvalificerede, mens domænenavne, der ikke slutter med et punktum, er relative i forhold til den aktuelle oprindelse (hvilket er grunden til, at www i ovenstående eksempel henviser til www.example.com).