Formatet för en zonfil definieras i RFC 1035 (avsnitt 5) och RFC 1034 (avsnitt 3.6.1). Formatet användes ursprungligen av programpaketet Berkeley Internet Name Domain (BIND), men har i stor utsträckning antagits av andra DNS-serverprogram – även om vissa av dem (t.ex. NSD, PowerDNS) endast använder zonfilerna som en utgångspunkt för att sammanställa dem i databasformat, se även Microsoft DNS with Active Directory-databasintegration.
En zonfil är en sekvens av radorienterade poster, där var och en av dem antingen är ett direktiv eller en textbeskrivning som definierar en enda resurspost (RR). En post består av fält som separeras av en valfri kombination av vitrymder (tabulatorer och mellanslag) och slutar vid en radgräns utom inom ett fältvärde för en citerad sträng eller ett par omslutande formateringsparenteser. Varje rad kan avslutas med kommentartext som föregås av ett semikolon, och filen kan också innehålla ett valfritt antal tomma rader.
Inträden kan förekomma i vilken ordning som helst i en zonfil, med vissa undantag.
Direktiv är kontrollposter som påverkar resten av zonfilen. Det första fältet i ett direktiv består av ett dollartecken följt av ett nyckelord:
- $ORIGIN följs av ett domännamn som ska användas som ursprung för efterföljande relativa domännamn.
- $INCLUDE följs av ett filnamn och ett valfritt ursprungsdomännamn som ska användas vid tolkning av innehållet (som behandlas som om det fanns i den överordnade filen, följt av en återställning till det ursprungsvärde som föregår utvärdering av direktivet).
- $TTL, definierat i RFC 2308 (avsnitt 4), följs av ett tal som ska användas som standard-TTL (time-to-live).
- $GENERATE, ett icke-standardiserat tillägg som accepteras av BIND och vissa andra namnservrar för att infoga flera resursposter med en post, följs av en kortfattad representation av en ökande sekvens av icke-negativa tal och därefter en mall för RR-post. En resurspost läggs till för varje nummer i sekvensen, med hjälp av mallen där oavslutade ”$”-tecken ersätts med numret.
En resurspost består av flera fält enligt följande (båda fältordningarna är godtagbara och kan användas omväxlande):
namn | ttl | rekordklass | rekordtyp | rekorddata |
namn | registreringsklass | ttl | registreringstyp | registreringsdata |
Namnfältet kan lämnas tomt. I så fall ärver posten fältet från den föregående posten. Ett fristående @ används för att ange det aktuella ursprunget.
Fältet ttl anger det antal sekunder efter vilket en cachingklient måste kasta posten och utföra en ny upplösningsoperation för att få ny information. Vissa namnservrar, inklusive BIND, tillåter icke-standardiserade representationer som använder förkortningar av tidsenheter (till exempel ”2d” som betyder två 24-timmarsdagar eller ”1h30m” som betyder en timme och 30 minuter). Det kan utelämnas, och i så fall kommer det resulterande värdet att ställas in från standard-TTL (om den är definierad) eller från den föregående posten.
Fältet för postklass anger namnområdet för postinformationen. Det kan utelämnas, i vilket fall det resulterande värdet kommer att sättas från den föregående posten. Det vanligaste namnområdet är Internet, vilket anges med parametern IN, men andra finns och används, t.ex. CHAOS.
Fältet record type är en förkortning för den typ av information som lagras i det sista fältet, record data. Till exempel: en adresspost (typ A för IPv4 eller typ AAAA för IPv6) mappar domännamnet från det första fältet till en IP-adress i postdata; en postväxlingspost (typ MX) anger SMTP-postvärd (Simple Mail Transfer Protocol) för en domän.
Fältet för postdata kan bestå av ett eller flera informationselement, beroende på kraven för varje posttyp. En adresspost kräver till exempel bara en adress, medan en postväxlarpost kräver en prioritet och ett domännamn. Sådana informationselement representeras som fält separerade med vitrymd.
ExempelfilRedigera
Ett exempel på en zonfil för domänen example.com är följande:
$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
Zonfilen måste som ett minimum specificera SOA-posten (Start of Authority) med namnet på den auktoritativa huvudnamnservern för zonen och e-postadressen till den som är ansvarig för hanteringen av namnservern (representerad som ett domännamn med ett punkttecken i stället för den vanliga symbolen @). Parametrarna i SOA-posten specificerar också en lista över parametrar för tid och förfall (serienummer, uppdateringsperiod för slav, försöksperiod för slav, förfallsperiod för slav och den maximala tiden för att lagra posten i cache). Vissa namnservrar, däribland BIND, kräver också minst en ytterligare NS-post.
I zonfilen är domännamn som slutar med ett punkttecken (som ”example.com.” i exemplet ovan) fullt kvalificerade, medan domännamn som inte slutar med ett punkttecken är relativa till det aktuella ursprunget (vilket är anledningen till att www i exemplet ovan hänvisar till www.example.com).