| | this delimiates fields |
# | This signifies a comment. Lines starting with this are ignored, otherwise it has no significance |
% | in domain names signifies that the rest of the domain name should be the name of this zone |
* | This is translated to mean "any host name that otherwise does not resolve". It must be at the beginning of a domain name. |
\ | This is used an an escape character, either to escape octal values such as '\045' for %, or to escape the '%' character so it has no special meaning, or to escape the backslash character. |
All domain-name labels are converted to their lower-case equivalents before processing is done. This is because domain-name literals in the database with one or more upper-case letters in them are case-sensitive. This is my way to resolve RFC1035 schizorphrenic desire to both allow binary domain labels, and its desire to be case-insensitive
The file must first have a SOA record, followed by one or more NS records, followed by other records. The initial NS and SOA records must be RR for this zone. NS records after any non-NS record must be part of another zone. The resolution algorithm will not break if non-CNAME records share records with a CNAME record, but this is not a good idea to do.
A domain name is a one-letter designation of its type, followed by the domain name serparated by dots, ending with either a % or a trailing dot. If the domain name does not end with a % or trailing dot, an error is returned (I hope to change this in a later relase of MaraDNS).
MaraDNS currently supports the following types of resource records (RRs):
Letter Type RFC1035 §3.2.2 value A A 1 N NS 2 C CNAME 5 S SOA 6 P PTR 12 @ MX 15 T TXT 16 U any determined in third field of line
Here are the formats, shown by letter name:
A: Has three fields field one: the domain name field two: the ttl for the name in seconds field three: the ip address, in dotted decimal notation Example: Ahost.example.com.|7200|10.1.2.3
A records are described with gruelling detail in RFC1035. In short, an A record is an IP address for a given host name.
N: Has three fields field one: the domain name of the record field two: the ttl for the name in seconds field three: the domain name this NS points to. Example: Nexample.com.|86400|ns.example.com.
NS (N here) records are described in RFC1035
C: Has three fields field one: the domain name of the record field two: the ttl for the name in seconds field three: the domain this CNAME record points to Example: Calias.example.org.|3200|realname.example.org.
CNAME (which C is short for) records are described in RFC1035
S: Has nine fields field one: the domain name of the record field two: the TTL of the record field three: the origin of the domain field four: the email address for this domain (in the RFC822, not BIND format) field five: the serial for the domain field six: the refresh (how often to see updates) for the domain field seven: the retry (how often to try when down) for the domain field eight: the expire (how long before the slave gives up) for the domain field nine: the minimum (and defalt) TTL for the domain Example: Sexample.net.|86400|example.net.|hostmaster@example.net.|19771108|7200|3600|604800|1800
SOA (S here) records are described in RFC1035
P: has three fields field one: the IP we wish to point to (in in-addr.arpa form) field two: the ttl for the name in seconds field three: the FQDN for the IP in question Example: P3.2.1.10.in-addr.arpa.|86400|ns.example.com.
PTR (P here) records are described in RFC1035
@: has four fields field one: The host that people send email to field two: the ttl for this record field three: The preference for this MX host field four: The name of this MX host Example: @example.com.|86400|10|mail.example.com.
MX (@ here) records are described in RFC1035
T: has three fields field one: The host someone wants to get additional informaiton about field two: the ttl for this record field three: The desired text. Any data becomes the record up until a new line is reached. The new line is not part of the TXT record Example: Texample.com.|86400|Example.com: Buy example products online
TXT (T here) records are described in RFC1035
U: has four fields field one: The host someone wants a datatype normally unsupported by MaraDNS field two: the ttl for this record field three: The numeric code for this data type (33 for SRV, etc.) field four: The raw binary data for this data type Example: Uexample.com|3600|40|\010\001\002Kitchen sink data
The above example is a "Kitchen Sink" RR (see draft-ietf-dnsind-kitchen-sink-02.txt) with a "meaning" of 8, a "coding" of 1, a "subcoding" of 2, and a data string of "Kitchen sink data". Since this particular datatype is not formallized in a RFC at this time, the most appropriate method of storing this data is by using the catch-all "unsupported" syntax.
# Zone file for example.com (example file) # The SOA record must be first, followed by all authoritative # NS records for this zone. Sexample.com.|86400|example.com.|hostmaster@example.com.|19771108|7200|3600|604800|1800 Nexample.com.|86400|ns1.example.com. Nexample.com.|86400|ns2.example.com. # Some 'IN A' records Aexample.com.|86400|10.1.2.3 Amx.example.com.|86400|10.1.2.4 Ans1.example.com.|86400|10.0.0.1 Ans2.example.com.|86400|192.168.0.1 # An 'IN MX' record @example.com.|86400|10|mx.example.com. # An 'IN CNAME' record Cwww.example.com.|86400|example.com. # An 'IN TXT' record Texample.com.|86400|Example.com: Buy examples of products online! # An 'A' record showing the use of percent as a shortcut for # the name of this zone (in this case, 'example.com.') Aftp.%|3600|10.7.8.9 # MaraDNS has support for wildcard records @*.example.com.|3600|10|mx.example.com. # A 'PTR' record which, while marked as unauthoritative, allows # this program to work with nslookup when bound on IP 127.0.0.3 P3.0.0.127.in-addr.arpa.|1234|nslookup.bug.workaround.