# This is an example csv2 zone file

# First of all, csv2 zone files do not need an SOA record; however, if
# one is provided, we will make it the SOA record for our zone
# The SOA record needs to be the first record in the zone if provided
# This is a commented out record and disabled.

#% 	SOA	% email@% 1 7200 3600 604800 1800 ~

# Second of all, csv2 zone files do not need authoritative NS records.
# If they aren't there, MaraDNS will synthesize them, based on the IP
# addresses MaraDNS is bound to.  (She's pretty smart about this; if
# Mara is bound to both public and private IPs, only the public IPs will
# be synthesized as NS records)


#% 	NS 	a.% ~
#%	NS	b.% ~

# Here are some A (ipv4 address) records; since this is the most
# common field, the zone file format allows a compact representation
# of it.
a.example.net. 	10.10.10.10 ~
# Here, you can see that a single name, "b.example.net." has multiple IPs
# This can be used as a primitive form of load balancing; MaraDNS will
# rotate the IPs so that first IP seen by a DNS client changes every time
# a query for "b.example.net." is made
b.example.net.  10.10.10.11 ~
b.example.net.  10.10.10.12 ~

# We can have the label in either case; it makes no difference
Z.EXAMPLE.NET. 	10.2.3.4 ~
Y.EXAMPLE.net.  10.3.4.5 ~

# We can use the percent shortcut.  When the percent shortcut is present,
# it indicates that the name in question should terminate with the name
# of the zone we are processing.
percent.%	a 		10.9.8.7 ~

# And we can have star records
#*.example.net.  A		10.11.12.13 ~

# We can have a ttl in a record; however the ttl needs a '+' before it:
# Note that the ttl has to be in seconds, and is before the RTYPE
d.example.net. +86400 A 10.11.12.13 ~

f.example.net. # As you can see, records can span multiple lines
        	A 	10.2.19.83 ~

# This allows well-commented records, like this:
c.example.net. 		# Our C class machine
        +86400  	# This record is stored for one day
        A       	# A record
        10.1.1.1 	# Where we are 
        ~               # End of record

# We can even have something similar to csv1 if we want...
e.example.net.|+86400|a|10.2.3.4|~
h.example.net.|a|10.9.8.7|~
# Here, we see we can specify the ttl but not the rtype if desired
g.example.net.|+86400|10.11.9.8|~

# Here is a MX record
# Note that "IN" is a pseudo-RR which means to ignore the RR type and
# look at the next RR type in the zone file; this allows MaraDNS zone
# files to look more like BIND zone files.
% mx 10 mail.% ~
mail.% +86400 IN A 10.22.23.24 ~

# We even have a bit of ipv6 support
a.example.net. 		aaaa 	2001:db8:1:2::3:f ~

# Not to mention support for SRV records
_http._tcp.%    srv   0 0 80 a.% ~

# TXT records, naturally
example.net.    txt 'This is some text' ~

# Starting with MaraDNS 1.2.08, there is also support for SPF records,
# which are identical to TXT records.  See RFC4408 for more details.
example.net.    spf 'v=spf1 +mx a:colo.example.com/28 -all' ~


