1CSV2(5)                        MaraDNS reference                       CSV2(5)
2
3
4

NAME

6       csv2 - Description of the csv2 zone file that MaraDNS uses
7

DESCRIPTION

9       The csv2 zone file format is MaraDNS' standard zone file format.  This
10       zone file format uses any kind of whitespace (space, tab, and carriage
11       return), or the '|' character, to delimit fields.
12
13    Tilde delimitation
14
15       In newer MaraDNS releases, the tilde ('~') character is used to delimit
16       records in csv2 zone files; in order to maintain maximum compatibility
17       with older MaraDNS zone files, this feature is only enabled if a tilde
18       is placed between the first and second record.  Otherwise, tildes are
19       not allowed in zone files (except in comments).
20
21       Most older MaraDNS csv2 zone files without the tilde character are
22       compatible with the updated csv2 parser, unless csv2_tilde_handling is
23       set to 3. All older MaraDNS csv2 zone files will parse in MaraDNS if
24       csv2_tilde_handling has a value of 0. Older MaraDNS releases also
25       supported the csv2_tilde_handling variable (as long as it had a value
26       of 0); this allowed the same configuration and zone files to be used in
27       older and newer MaraDNS releases.
28
29    Resource record format
30
31       This zone file format has records in the following form:
32
33           name [+ttl] [rtype] rdata ~
34
35       The name is the name of the record we will add, such as
36       "www.example.net.". This must be placed at the beginning of a line. The
37       rtype is the record type for the record, such as "A" (ipv4 IP address),
38       "MX" (mail exchanger), or "AAAA" (ipv6 IP address). The ttl is how long
39       other DNS servers should store this data in their memory (in seconds);
40       this field needs a '+' as its initial character. The rdata is the
41       actual data for this record; the format for the rdata is type-specific.
42
43       Anything in square brackets is an optional field. If the ttl is not
44       specified, the ttl is set to the default ttl value (see "Default TTL"
45       below). If the rtype is not specified, it is set to be an "A" (ipv4
46       address) record.
47
48       The zone file supports comments; comments are specified by having a '#'
49       anywhere between fields or records; when a '#' is seen, the csv2 parser
50       ignores any character it sees (with the exception of the '{', which is
51       not allowed in comments) until a newline. A '#' can usually be placed
52       inside a field, and indicates the end of a field when placed there.
53
54       A '{' character can never be placed in a comment. A '~' character is
55       always allowed in a comment, and has no special meaning when placed in
56       a comment.
57
58       The following record types are supported; a description of the record
59       data format accommodates the record type:
60
61    A
62
63       An A record stores an ipv4 address. This is the default record type
64       should the record type not be specified. The record type has one field
65       in it: the IP for the record. Examples:
66
67       a.example.net.              10.11.12.13 ~
68       b.example.net.        A     10.11.12.14 ~
69       c.example.net. +64000 A     10.11.12.15 ~
70
71    PTR
72
73       A PTR record stores the name for a given ipv4 or ipv6 address, and is
74       used for reverse DNS lookups. This record type has one field in it: The
75       name for the record in question. Examples:
76
77       13.12.11.10.in-addr.arpa.        PTR    a.example.net. ~
78       14.12.11.10.in-addr.arpa.        PTR    b.example.net. ~
79       15.12.11.10.in-addr.arpa. +64000 PTR    c.example.net. ~
80
81    MX
82
83       A MX record stores a mail exchange record, and is used for mail
84       delivery. This record type has two fields in it: The priority (or
85       "preference" in traditional DNS parlance) of the MX record (lower
86       numbers get higher priority), and the name of the mail exchanger.
87       Example of mail for example.net being mailed to mail.example.net, which
88       has the IP "10.11.12.16":
89
90       example.net.      MX   10 mail.example.net. ~
91       mail.example.net.      10.11.12.16 ~
92
93    AAAA
94
95       An AAAA record stores the ipv6 address for a given name. The IP is in
96       standard ipv6 "colon delimited" format: eight 16-bit hexadecimal
97       numbers are separated by colons. Two colons together indicate multiple
98       streams of all-zero hex numbers. This record has only one field, the v6
99       IP. Example:
100
101       a.example.net.   AAAA    2001:db8:dec:ade::f ~
102
103    SRV
104
105       An SRV record stores a "service" definition. This record has four
106       fields: Priority, weight, port, and target. For more information,
107       please refer to RFC 2782. Example:
108
109       _http._tcp.% SRV 0 0 80 a.% ~
110
111    NAPTR
112
113       A NAPTR record is described in RFC 2915. Example:
114
115       www.example.com. NAPTR 100 100 's';'http+I2R';'' _http._tcp.example.com. ~
116
117       Note the semicolons. Because of a bug in MaraDNS 1.4.03 and earlier
118       releases, NAPTR records will not parse unless a ~ is not used to
119       separate records; a patch to fix this bug is available here.
120
121    NS
122
123       An NS record specifies the name servers for a given zone. If the name
124       servers are not delegation name servers (in other words, if the name
125       servers are the authoritative name servers for the zone), they need to
126       be at the beginning of the zone, either as the first records in the
127       zone, or right after the SOA record. The NS records are optional; if
128       not present, MaraDNS will make an educated guess of that NS records
129       should be there, based on the IPs the MaraDNS process is bound to. This
130       record has one field: The name of the name server machine. Example:
131
132       example.net.    NS    ns1.example.net. ~
133       example.net.    NS    ns2.example.net. ~
134
135    SOA
136
137       An SOA record stores the start of authority for a given zone file. This
138       record is optional in a CSV2 zone file; should the record not be in the
139       zone file, MaraDNS will synthesize an appropriate SOA record. This
140       record can only exist once in a zone file: As the first record of the
141       zone file. This record has seven fields: The name of the zone, the
142       email address of the person responsible for the zone, and five numeric
143       fields (serial, refresh, retry, expire, and minimum). Note that the SOA
144       minimum does not affect other TTLs in MaraDNS. Example:
145
146       x.org. SOA x.org. email@x.org. 1 7200 3600 604800 1800 ~
147
148       If there is a '.' (dot) character in the part of the email address
149       before the '@', it needs to be escaped thusly:
150
151       x.org. SOA x.org. john\.doe@x.org. 1 7200 3600 604800 1800 ~
152
153       Note that the csv2 parser will not allow more than one dot in a row;
154       'john\.\.doe@x.org' will cause a parse error. In addition, the dot
155       character must be escaped with a backslash.
156
157       The serial numeric field may be replaced by the string '/serial'; this
158       string tells the CSV2 zone parser to synthesize a serial number for the
159       zone based on the timestamp for the zone file. This allows one to have
160       the serial number be automatically updated whenever the zone file is
161       edited. Here is how this special field looks in a SOA record:
162
163       x.org. SOA x.org. email@x.org. /serial 7200 3600 604800 1800 ~
164
165       The '/serial' string is case-sensitive; only '/serial' in all lower
166       case will parse.
167
168    TXT
169
170       A TXT record stores arbitrary text and/or binary data for a given host
171       name. This record has one field: The text data for the record.
172
173       A basic text record can be stored by placing ASCII data between two
174       single quotes, as follows:
175
176       example.com. TXT 'This is an example text field' ~
177
178       Any binary data can be specified; see the csv2_txt(5) manual page for
179       full details.
180
181       If tildes are used to separate records, a TXT record can not contain a
182       literal '|' (pipe) character, a '#' literal, a '~' literal, nor any
183       ASCII control literal; these characters can be added to a TXT record
184       via the use of escape sequences; read the csv2_txt man page for
185       details.
186
187    SPF
188
189       A SPF record is, with the exception of the numeric rtype, identical to
190       a TXT record. SPF records are designed to make it more difficult to
191       forge email.
192
193       Here is one example SPF record:
194
195       example.com. SPF 'v=spf1 +mx a:colo.example.com/28 -all' ~
196
197       Use '\x7e' to put a tilde ("~" character) in a SPF record:
198
199       example.com. SPF 'v=spf1 +mx a:colo.example.com/28 '\x7e'all' ~
200
201       More information about SPF records can be found in RFC4408, or by
202       performing a web search for 'sender policy framework'.
203
204       Note that SPF records never gained traction, and their role is handled
205       by TXT records.
206
207    RAW
208
209       The RAW record is a special meta-record that allows any otherwise
210       unsupported record type to be stored in a csv2 zone file. The syntax
211       is:
212
213       RAW [numeric rtype] [data] ~
214
215       The numeric rtype is a decimal number.
216
217       The data field can, among other thing, have backslashed hex sequences
218       outside of quotes, concatenated by ASCII data inside quotes, such as
219       the following example:
220
221       example.com. RAW 40 \x10\x01\x02'Kitchen sink'\x40' data' ~
222
223       The above example is a "Kitchen Sink" RR with a "meaning" of 16, a
224       "coding" of 1, a "subcoding" of 2, and a data string of "Kitchen sink@
225       data" (since hex code 40 corresponds to a @ in ASCII). Note that
226       unquoted hex sequences are concatenated with quoted ASCII data, and
227       that spaces are only inside quoted data.
228
229       The format for a data field in a RAW record is almost identical to the
230       format for a TXT data field. Both formats are described in full in the
231       csv2_txt(5) manual page.
232
233    FQDN4
234
235       The FQDN4 (short for "Fully Qualified Domain Name for IPv4") record is
236       a special form of the "A" record (see above) that instructs MaraDNS to
237       automatically create the corresponding PTR record. For example, the
238       following is one way of setting up the reverse DNS lookup for
239       x.example.net:
240
241       x.example.net. A 10.3.28.79 ~
242       79.28.3.10.in-addr.arpa. PTR x.example.net. ~
243
244       But the above two lines in a zone file can also be represented thusly:
245
246       x.example.net. FQDN4 10.3.28.79 ~
247
248       Note that the csv2 parser does not bother to check that any given IP
249       only has a single FQDN4 record; it is up to the DNS administrator to
250       ensure that a given IP has only one FQDN4 record. In the case of there
251       being multiple FQDN4 records with the same IP, MaraDNS will have
252       multiple entries in the corresponding PTR record, which is usually not
253       the desired behavior.
254
255       FQDN4 records are not permitted in a csv2_default_zonefile. If you do
256       not know what a csv2_default_zonefile is, you do not have to worry
257       about this limitation.
258
259    FQDN6
260
261       The FQDN6 (short for "Fully Qualified Domain Name for IPv6") record is
262       the ipv6 form for the FQDN4 record. Like the FQDN4 record, this record
263       creates both a "forward" and "reverse" DNS record for a given host
264       name. For example, one may have:
265
266       x.example.net. AAAA 2001:db8:dec:ade::b:c:d ~
267       d.0.0.0.c.0.0.0.b.0.0.0.0.0.0.0.e.d.a.0.c.e.d.0.8.b.d.0.1.0.0.2 PTR
268       x.example.net. ~
269
270       But the above two lines in a zone file can also be represented thusly:
271
272       x.example.net. FQDN6 2001:db8:dec:ade::b:c:d ~
273
274       Like FQDN4 records, it is the DNS administrator's duty to make sure
275       only a single IP has a FQDN6 record.
276
277       FQDN6 records are, like FQDN4 records, not permitted in a
278       csv2_default_zonefile. If you do not know what a csv2_default_zonefile
279       is, you do not have to worry about this limitation.
280
281       FQDN6 records were implemented by Jean-Jacques Sarton.
282
283    CNAME
284
285       A CNAME record is a pointer to another host name. The CNAME record, in
286       MaraDNS, affects any record type not already specified for a given host
287       name. While MaraDNS allows CNAME and non-CNAME records to share the
288       same host name, this is considered bad practice and is not compatible
289       with some other DNS servers.
290
291       CNAME records are not permitted in a csv2_default_zonefile. If you do
292       not know what a csv2_default_zonefile is, this fact is of no relevance.
293

Historical and uncommon resource records

295       The following resource records are mainly of historical interest, or
296       are not commonly used.
297
298    HINFO
299
300       In light of RFC8482, using this record type is strongly discouraged.
301
302       An HINFO record is a description of the CPU (processor) and OS that a
303       given host is using. The format for this record is identical to a TXT
304       record, except that the field must have precisely two chunks.
305
306       The first chunk of a HINFO record is the CPU the host is running; the
307       second chunk is the OS the host is running.
308
309       Example:
310
311       example.com. HINFO 'Intel Pentium III';'CentOS Linux 3.7' ~
312
313       This resource record is not actively used--the IANA has a list of CPUs
314       and OSes that this record is supposed to have. However, this list has
315       not been updated since 2002.
316
317       Since MaraDNS has support for RFC8482, ANY queries sent to MaraDNS will
318       return an HINFO record with a CPU of "RFC8482" and a blank OS name.
319
320    WKS
321
322       WKS records are historical records which have been superseded by SRV
323       records. The format of the record is an IP, followed by a protocol
324       number (6 means TCP), followed by a list of ports that a given server
325       has available for services.
326
327       For example, to advertise that example.net has the IP 10.1.2.3, and has
328       a SSH, HTTP (web), and NNTP server:
329
330       example.net. WKS 10.1.2.3 6 22,80,119 ~
331
332       MaraDNS only allows up to 10 different port numbers in a WKS record,
333       and requires that the listed port numbers not be higher than 1023.
334
335    MD and MF
336
337       MD and MF records are RR types that existed before MX records, and were
338       made obsolete by MX records. RFC1035 says that a DNS server can either
339       reject these records or convert these records in to MX records. BIND
340       rejects these records; MaraDNS converts them.
341
342       Example:
343
344       example.net. MD a.example.net. ~
345       example.net. MF b.example.net. ~
346
347       Is equivalent to:
348
349       example.net. MX 0 a.example.net. ~
350       example.net. MX 10 b.example.net. ~
351
352    MB, MG, MINFO, and MR
353
354       In the late 1980s, an alternative to MX records was proposed. This
355       alternative utilized MB, MG, MINFO, and MR records. This alternative
356       failed to gather popularity. However, these records were codified in
357       RFC1035, and are supported by MaraDNS. Here is what the records look
358       like:
359
360       example.net. MB mail.example.net. ~
361       example.net. MG mg@example.net. ~
362       example.net. MINFO rm@example.net. re@example.net. ~
363       example.net. MR mr@example.net. ~
364
365       More information about these records can be found in RFC1035.
366
367    AFSDB, RP, X25, ISDN, and RT
368
369       AFSDB, RP, X25, ISDN, and RT are resource records which were proposed
370       in RFC1183. None of these resource records are widely used.
371
372       With the exception of the ISDN record, the format of these records is
373       identical to the examples in RFC1183. The format of the ISDN record is
374       identical unless the record has a subaddress (SA). If an ISDN record
375       has a subaddress, it is separated from the ISDN-address by a ';'
376       instead of whitespace.
377
378       If used, here is how the records would look in a csv2 zone file:
379
380       example.net. AFSDB 1 afsdb.example.net. ~
381       example.net. RP rp@example.net. rp.example.net. ~
382       example.net. RP rp2@example.net. . ~
383       example.net. X25 311061700956 ~
384       example.net. ISDN 150862028003217 ~
385       example.net. ISDN 150862028003217;004 ~
386       example.net. RT 10 relay.example.net. ~
387
388    NSAP and NSAP-PTR
389
390       NSAP and NSAP-PTR records were proposed in RFC1706. A NSAP record is a
391       hexadecimal number preceded by the string "0x" and with optional dots
392       between bytes. This hexadecimal number is converted in to a binary
393       number by MaraDNS. A NSAP-PTR record is identical to a PTR record, but
394       has a different RTYPE.
395
396       More information about these records can be obtained from RFC1706.
397
398       If used, here is how the records would look in a csv2 zone file:
399
400       example.net. NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00 ~
401       example.net. NSAP-PTR nsap.example.net. ~
402
403    PX
404
405       The PX RR is an obscure RR described in RFC2163. A PX record looks like
406       this in a CSV2 zone file:
407
408       example.net. PX 15 px1.example.net. px2.example.net. ~
409
410    GPOS
411
412       An GPOS record is a description of the location of a given server. The
413       format for this record is identical to a TXT record, except that the
414       field must have precisely three chunks.
415
416       The first chunk of a GPOS record is the longitude; the second chunk is
417       the latitude; the third chunk is the altitude (in meters).
418
419       Example:
420
421       example.net. GPOS '-98.6502';'19.283';'2134' ~
422
423       More information about this record can be found in RFC1712.
424
425       This resource record is not actively used; for the relatively few
426       people who encode their position in DNS, the LOC record is far more
427       common.
428
429    LOC
430
431       The LOC resource record is an uncommonly used resource record that
432       describes the position of a given server. LOC records are described in
433       RFC1876.
434
435       Note that MaraDNS' LOC parser assumes that the altitude, size,
436       horizontal, and vertical precision numbers are always expressed in
437       meters. Also note that that sub-meter values for size, horizontal, and
438       vertical precision are not allowed. Additionally, the altitude can not
439       be greater than 21374836.47 meters.
440
441       Example:
442
443       example.net. LOC 19 31 2.123 N 98 3 4 W 2000m 2m 4m 567m ~
444
445    CAA
446
447       MaraDNS does not have direct support for CAA records. However, the RAW
448       record type can generate CAA records. For example, to have
449       "example.com" have a CAA record with the value of "issue
450       letsencrypt.org":
451
452       example.com. RAW 257 \x00\x05'issueletsencrypt.org' ~
453

STAR RECORDS

455       MaraDNS has support for star records in zone files:
456
457       *.example.net.  A        10.11.12.13 ~
458
459       In this example, anything.example.net will have the IP 10.11.12.13.
460       Note that this does not set the ip for "example.net", which needs a
461       separate record:
462
463       example.net.  A                 10.11.12.13 ~
464
465       Note also that stars must be at the beginining of a name; to have stars
466       at the end of a name, use the csv2_default_zonefile feature as
467       described in the mararc man page.
468

PERCENT SYMBOL

470       Placing the percent symbol at the end of a record indicates that the
471       percent should be replaced with the domain name for the zone.
472
473       For example, in the zone for example.net. (e.g. one's mararc file has
474       csv2["example.net."] = "db.example.net", and we are editing the
475       "db.example.net" file):
476
477       www.%     A    10.10.10.10 ~
478
479       This will cause "www.example.net" to have the ip 10.10.10.10.
480

SLASH COMMANDS

482       In addition to being able to have resource records and comments, csv2
483       zone files can also have special slash commands. These slash commands,
484       with the exception of the '/serial' slash command (see "SOA" above),
485       can only be placed where the name for a record would be placed.  Like
486       resource records, a tilde is to be placed after the slash command.
487       Note also that slash commands are case-sensitive, and the command in
488       question must be in all-lower-case.
489
490       These commands are as follows:
491
492    Default TTL
493
494       The default TTL is the TTL for a resource record without a TTL
495       specified. This can be changed with the '/ttl' slash command.  This
496       command takes only a single argument: The time, in seconds, for the new
497       default TTL. The '/ttl' slash command only affects the TTL of records
498       that follow the command. A zone file can have multiple '/ttl' slash
499       commands.
500
501       The default TTL is 86400 seconds (one day) until changed by the '/ttl'
502       slash command.
503
504       In the following example, a.ttl.example.com will have a TTL of 86400
505       seconds (as long as the zone file with this record has not previously
506       used the '/ttl' slash command), b.ttl.example.com and d.ttl.example.com
507       will have a TTL of 3600 seconds, c.ttl.example.com will have a TTL of
508       9600 seconds, and e.ttl.example.com will have a TTL of 7200 seconds:
509
510       a.ttl.example.com.       10.0.0.1 ~
511       /ttl 3600 ~
512       b.ttl.example.com.       10.0.0.2 ~
513       c.ttl.example.com. +9600 10.0.0.3 ~
514       d.ttl.example.com.       10.0.0.4 ~
515       /ttl 7200 ~
516       e.ttl.example.com.       10.0.0.5 ~
517
518    Origin
519
520       It is possible to change the host name suffix that is used to
521       substitute the percent in a csv2 zone file. This suffix is called, for
522       historical and compatibility reasons, "origin". This is done as the
523       slash command '/origin', taking the new origin as the one argument to
524       this function. Note that changing the origin does not change the domain
525       suffix used to determine whether a given domain name is authoritative.
526
527       Here is one example usage of the '/origin' slash command:
528
529       /origin example.com. ~
530       www.% 10.1.0.1 ~
531       % MX 10 mail.% ~
532       mail.% 10.1.0.2 ~
533       /origin example.org. ~
534       www.% 10.2.0.1 ~
535       % MX 10 mail.% ~
536       mail.% 10.2.0.2 ~
537
538       Which is equivalent to:
539
540       www.example.com. 10.1.0.1 ~
541       example.com. MX 10 mail.example.com. ~
542       mail.example.com. 10.1.0.2 ~
543       www.example.org. 10.2.0.1 ~
544       example.org. MX 10 mail.example.org. ~
545       mail.example.org. 10.2.0.2 ~
546
547       It is also possible to make the current origin be part of the new
548       origin:
549
550       /origin example.com. ~
551       % 10.3.2.1 ~ # example.com now has IP 10.3.2.1
552       /origin mail.% ~
553       % 10.3.2.2 ~ # mail.example.com now has IP 10.3.2.2
554
555    Opush and Opop
556
557       The '/opush' and '/opop' slash commands use a stack to remember and
558       later recall values for the origin (see origin above). The '/opush'
559       command is used just like the '/origin' command; however, the current
560       origin is placed on a stack instead of discarded.  The '/opop' command
561       removes ("pops") the top element from this stack and makes the element
562       the origin.
563
564       For example:
565
566       /origin example.com. ~
567       /opush mail.% ~ # origin is now mail.example.com; example.com is on stack
568       a.% 10.4.0.1 ~ # a.mail.example.com has IP 10.4.0.1
569       /opush web.example.com. ~ # mail.example.com and example.com are on stack
570       a.% 10.5.0.1 ~ # a.web.example.com has IP 10.5.0.1
571       b.% 10.5.0.2 ~ # b.web.example.com has IP 10.5.0.2
572       /opop ~ # origin is now mail.example.com again
573       b.% 10.4.0.2 ~ # b.mail.example.com has IP 10.4.0.2
574       /opop ~ # origin is now example.com
575       % MX 10 a.mail.% ~ # example.com. MX 10 a.mail.example.com.
576       % MX 20 b.mail.% ~ # example.com. MX 20 b.mail.example.com.
577
578       The opush/opop stack can have up to seven elements on it.
579
580    Read
581
582       The '/read' slash commands allows one to have the contents of another
583       file in a zone. The '/read' command takes a single argument: A filename
584       that one wishes to read. The filename is only allowed to have letters,
585       numbers, the '-' character, the '_' character, and the '.' character in
586       it.
587
588       The file needs to be in the same directory as the zone file. The file
589       will be read with the same privileges as the zone file; content in the
590       file should come from a trusted source or be controlled by the system
591       administrator.
592
593       Let us suppose that we have the following in a zone file:
594
595       mail.foo.example.com. 10.3.2.1 ~
596       /read foo ~
597       foo.example.com. MX 10 mail.foo.example.com. ~
598
599       And a file foo with the following contents:
600
601       foo.example.com. 10.1.2.3 ~
602       foo.example.com. TXT 'Foomatic!' ~
603
604       Then foo.example.com will have an A record with the value 10.1.2.3, a
605       TXT value of 'Foomatic!', and a MX record with priority 10 pointing to
606       mail.foo.example.com. mail.foo.example.com will have the IP 10.3.2.1.
607
608       Note that no pre-processing nor post-processing of the origin is done
609       by the '/read' command; should the file read change the origin, this
610       changed value will affect any records after the '/read' command. For
611       example, let us suppose db.example.com looks like this:
612
613       /origin foo.example.com. ~
614       % TXT 'Foomatic!' ~
615       /read foo ~
616       % MX 10 mail.foo.example.com. ~
617
618       And the file foo looks like this:
619
620       % 10.1.2.3 ~
621       /origin mail.% ~
622       % 10.3.2.1 ~
623
624       Then the following records will be created:
625
626       foo.example.com.      TXT   'Foomatic!' ~
627       foo.example.com.      A     10.1.2.3 ~
628       mail.foo.example.com. A     10.3.2.1 ~
629       mail.foo.example.com. MX 10 mail.foo.example.com. ~
630
631       To have something that works like '$INCLUDE filename' in a RFC1035
632       master file, do the following:
633
634       /opush % ~
635       /read filename ~
636       /opop ~
637
638       Or, for that matter, the equivalent of '$INCLUDE filename neworigin':
639
640       /opush neworigin. ~
641       /read filename ~
642       /opop ~
643

EXAMPLE ZONE FILE

645       # This is an example csv2 zone file
646
647       # First of all, csv2 zone files do not need an SOA record; however, if
648       # one is provided, we will make it the SOA record for our zone
649       # The SOA record needs to be the first record in the zone if provided
650       # This is a commented out record and disabled.
651
652       #%   SOA  % email@% 1 7200 3600 604800 1800 ~
653
654       # Second of all, csv2 zone files do not need authoritative NS records.
655       # If they aren't there, MaraDNS will synthesize them, based on the IP
656       # addresses MaraDNS is bound to.  (She's pretty smart about this; if
657       # Mara is bound to both public and private IPs, only the public IPs will
658       # be synthesized as NS records)
659
660       #%   NS   a.% ~
661       #%   NS   b.% ~
662
663       # Here are some A (ipv4 address) records; since this is the most
664       # common field, the zone file format allows a compact representation
665       # of it.
666       a.example.net.      10.10.10.10 ~
667       # Here, you can see that a single name, "b.example.net." has multiple IPs
668       # This can be used as a primitive form of load balancing; MaraDNS will
669       # rotate the IPs so that first IP seen by a DNS client changes every time
670       # a query for "b.example.net." is made
671       b.example.net.  10.10.10.11 ~
672       b.example.net.  10.10.10.12 ~
673
674       # We can have the label in either case; it makes no difference
675       Z.EXAMPLE.NET.      10.2.3.4 ~
676       Y.EXAMPLE.net.  10.3.4.5 ~
677
678       # We can use the percent shortcut.  When the percent shortcut is present,
679       # it indicates that the name in question should terminate with the name
680       # of the zone we are processing.
681       percent.% a         10.9.8.7 ~
682
683       # And we can have star records
684       #*.example.net.  A       10.11.12.13 ~
685
686       # We can have a ttl in a record; however the ttl needs a '+' before it:
687       # Note that the ttl has to be in seconds, and is before the RTYPE
688       d.example.net. +86400 A 10.11.12.13 ~
689
690       f.example.net. # As you can see, records can span multiple lines
691                 A    10.2.19.83 ~
692
693       # This allows well-commented records, like this:
694       c.example.net.           # Our C class machine
695               +86400      # This record is stored for one day
696               A           # A record
697               10.1.1.1    # Where we are
698               ~               # End of record
699
700       # We can even have something similar to csv1 if we want...
701       e.example.net.|+86400|a|10.2.3.4|~
702       h.example.net.|a|10.9.8.7|~
703       # Here, we see we can specify the ttl but not the rtype if desired
704       g.example.net.|+86400|10.11.9.8|~
705
706       # Here is a MX record
707       # Note that "IN" is a pseudo-RR which means to ignore the RR type and
708       # look at the next RR type in the zone file; this allows MaraDNS zone
709       # files to look more like BIND zone files.
710       % mx 10 mail.% ~
711       mail.% +86400 IN A 10.22.23.24 ~
712
713       # We even have a bit of ipv6 support
714       a.example.net.           aaaa      2001:db8:1:2::3:f ~
715
716       # Not to mention support for SRV records
717       _http._tcp.%    srv   0 0 80 a.% ~
718
719       # TXT records, naturally
720       example.net.    txt 'This is some text' ~
721
722       # Starting with MaraDNS 1.2.08, there is also support for SPF records,
723       # which are identical to TXT records.  See RFC4408 for more details.
724       example.net.    spf 'v=spf1 +mx a:colo.example.com/28 -all' ~
725
726
728       THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR
729       IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
730       WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
731       DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR
732       ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
733       DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
734       OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
735       HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
736       STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
737       IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
738       POSSIBILITY OF SUCH DAMAGE.
739

AUTHOR

741       Sam Trenholme http://www.samiam.org/
742
743
744
745
746MARADNS                          January 2007                          CSV2(5)
Impressum