1CSV2(5) MaraDNS reference CSV2(5)
2
6 csv2 - Description of the csv2 zone file that MaraDNS uses
7
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 Tilde delimitation
14 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 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 Resource record format
30 This zone file format has records in the following form:
32 name [+ttl] [rtype] rdata ~
34 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 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 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 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 The following record types are supported; a description of the record
59 data format accommodates the record type:
60 A
62 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 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 PTR
72 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 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 MX
82 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 example.net. MX 10 mail.example.net. ~
91 mail.example.net. 10.11.12.16 ~
92 AAAA
94 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 a.example.net. AAAA 2001:db8:dec:ade::f ~
102 SRV
104 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 _http._tcp.% SRV 0 0 80 a.% ~
110 NAPTR
112 A NAPTR record is described in RFC 2915. Example:
114 www.example.com. NAPTR 100 100 's';'http+I2R';'' _http._tcp.example.com. ~
116 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 NS
122 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 example.net. NS ns1.example.net. ~
133 example.net. NS ns2.example.net. ~
134 SOA
136 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 x.org. SOA x.org. email@x.org. 1 7200 3600 604800 1800 ~
147 If there is a '.' (dot) character in the part of the email address
149 before the '@', it needs to be escaped thusly:
150 x.org. SOA x.org. john\.doe@x.org. 1 7200 3600 604800 1800 ~
152 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 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 x.org. SOA x.org. email@x.org. /serial 7200 3600 604800 1800 ~
164 The '/serial' string is case-sensitive; only '/serial' in all lower
166 case will parse.
167 TXT
169 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 A basic text record can be stored by placing ASCII data between two
174 single quotes, as follows:
175 example.com. TXT 'This is an example text field' ~
177 Any binary data can be specified; see the csv2_txt(5) manual page for
179 full details.
180 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 SPF
188 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 Here is one example SPF record:
194 example.com. SPF 'v=spf1 +mx a:colo.example.com/28 -all' ~
196 Use '\x7e' to put a tilde ("~" character) in a SPF record:
198 example.com. SPF 'v=spf1 +mx a:colo.example.com/28 '\x7e'all' ~
200 More information about SPF records can be found in RFC4408, or by
202 performing a web search for 'sender policy framework'.
203 Note that SPF records never gained traction, and their role is handled
205 by TXT records.
206 RAW
208 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 RAW [numeric rtype] [data] ~
214 The numeric rtype is a decimal number.
216 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 example.com. RAW 40 \x10\x01\x02'Kitchen sink'\x40' data' ~
222 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 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 FQDN4
234 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 x.example.net. A 10.3.28.79 ~
242 79.28.3.10.in-addr.arpa. PTR x.example.net. ~
243 But the above two lines in a zone file can also be represented thusly:
245 x.example.net. FQDN4 10.3.28.79 ~
247 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 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 FQDN6
260 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 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 But the above two lines in a zone file can also be represented thusly:
271 x.example.net. FQDN6 2001:db8:dec:ade::b:c:d ~
273 Like FQDN4 records, it is the DNS administrator's duty to make sure
275 only a single IP has a FQDN6 record.
276 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 FQDN6 records were implemented by Jean-Jacques Sarton.
282 CNAME
284 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 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
295 The following resource records are mainly of historical interest, or
296 are not commonly used.
297 HINFO
299 An HINFO record is a description of the CPU (processor) and OS that a
301 given host is using. The format for this record is identical to a TXT
302 record, except that the field must have precisely two chunks.
303 The first chunk of a HINFO record is the CPU the host is running; the
305 second chunk is the OS the host is running.
306 Example:
308 example.com. HINFO 'Intel Pentium III';'CentOS Linux 3.7' ~
310 This resource record is not actively used--the IANA has a list of CPUs
312 and OSes that this record is supposed to have. However, this list has
313 not been updated since 2002.
314 WKS
316 WKS records are historical records which have been superseded by SRV
318 records. The format of the record is an IP, followed by a protocol
319 number (6 means TCP), followed by a list of ports that a given server
320 has available for services.
321 For example, to advertise that example.net has the IP 10.1.2.3, and has
323 a SSH, HTTP (web), and NNTP server:
324 example.net. WKS 10.1.2.3 6 22,80,119 ~
326 MaraDNS only allows up to 10 different port numbers in a WKS record,
328 and requires that the listed port numbers are not be higher than 1023.
329 MD and MF
331 MD and MF records are RR types that existed before MX records, and were
333 made obsolete by MX records. RFC1035 says that a DNS server can either
334 reject these records or convert these records in to MX records. BIND
335 rejects these records; MaraDNS converts them.
336 Example:
338 example.net. MD a.example.net. ~
340 example.net. MF b.example.net. ~
341 Is equivalent to:
343 example.net. MX 0 a.example.net. ~
345 example.net. MX 10 b.example.net. ~
346 MB, MG, MINFO, and MR
348 In the late 1980s, an alternative to MX records was proposed. This
350 alternative utilized MB, MG, MINFO, and MR records. This alternative
351 failed to gather popularity. However, these records were codified in
352 RFC1035, and are supported by MaraDNS. Here is what the records look
353 like:
354 example.net. MB mail.example.net. ~
356 example.net. MG mg@example.net. ~
357 example.net. MINFO rm@example.net. re@example.net. ~
358 example.net. MR mr@example.net. ~
359 More information about these records can be found in RFC1035.
361 AFSDB, RP, X25, ISDN, and RT
363 AFSDB, RP, X25, ISDN, and RT are resource records which were proposed
365 in RFC1183. None of these resource records are widely used.
366 With the exception of the ISDN record, the format of these records is
368 identical to the examples in RFC1183. The format of the ISDN record is
369 identical unless the record has a subaddress (SA). If an ISDN record
370 has a subaddress, it is separated from the ISDN-address by a ';'
371 instead of whitespace.
372 If used, here is how the records would look in a csv2 zone file:
374 example.net. AFSDB 1 afsdb.example.net. ~
376 example.net. RP rp@example.net. rp.example.net. ~
377 example.net. RP rp2@example.net. . ~
378 example.net. X25 311061700956 ~
379 example.net. ISDN 150862028003217 ~
380 example.net. ISDN 150862028003217;004 ~
381 example.net. RT 10 relay.example.net. ~
382 NSAP and NSAP-PTR
384 NSAP and NSAP-PTR records were proposed in RFC1706. A NSAP record is a
386 hexadecimal number preceded by the string "0x" and with optional dots
387 between bytes. This hexadecimal number is converted in to a binary
388 number by MaraDNS. A NSAP-PTR record is identical to a PTR record, but
389 has a different RTYPE.
390 More information about these records can be obtained from RFC1706.
392 If used, here is how the records would look in a csv2 zone file:
394 example.net. NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00 ~
396 example.net. NSAP-PTR nsap.example.net. ~
397 PX
399 The PX RR is an obscure RR described in RFC2163. A PX record looks like
401 this in a CSV2 zone file:
402 example.net. PX 15 px1.example.net. px2.example.net. ~
404 GPOS
406 An GPOS record is a description of the location of a given server. The
408 format for this record is identical to a TXT record, except that the
409 field must have precisely three chunks.
410 The first chunk of a GPOS record is the longitude; the second chunk is
412 the latitude; the third chunk is the altitude (in meters).
413 Example:
415 example.net. GPOS '-98.6502';'19.283';'2134' ~
417 More information about this record can be found in RFC1712.
419 This resource record is not actively used; for the relatively few
421 people who encode their position in DNS, the LOC record is far more
422 common.
423 LOC
425 The LOC resource record is an uncommonly used resource record that
427 describes the position of a given server. LOC records are described in
428 RFC1876.
429 Note that MaraDNS' LOC parser assumes that the altitude, size,
431 horizontal, and vertical precision numbers are always expressed in
432 meters. Also note that that sub-meter values for size, horizontal, and
433 vertical precision are not allowed. Additionally, the altitude can not
434 be greater than 21374836.47 meters.
435 Example:
437 example.net. LOC 19 31 2.123 N 98 3 4 W 2000m 2m 4m 567m ~
439 CAA
441 MaraDNS does not have direct support for CAA records. However, the RAW
443 record type can generate CAA records. For example, to have
444 "example.com" have a CAA record with the value of "issue
445 letsencrypt.org":
446 example.com. RAW 257 \x00\x05'issueletsencrypt.org' ~
448
450 MaraDNS has support for star records in zone files:
451 *.example.net. A 10.11.12.13 ~
453 In this example, anything.example.net will have the IP 10.11.12.13.
455 Note that this does not set the ip for "example.net", which needs a
456 separate record:
457 example.net. A 10.11.12.13 ~
459 Note also that stars must be at the beginining of a name; to have stars
461 at the end of a name, use the csv2_default_zonefile feature as
462 described in the mararc man page.
463
465 Placing the percent symbol at the end of a record indicates that the
466 percent should be replaced with the domain name for the zone.
467 For example, in the zone for example.net. (e.g. one's mararc file has
469 csv2["example.net."] = "db.example.net", and we are editing the
470 "db.example.net" file):
471 www.% A 10.10.10.10 ~
473 This will cause "www.example.net" to have the ip 10.10.10.10.
475
477 In addition to being able to have resource records and comments, csv2
478 zone files can also have special slash commands. These slash commands,
479 with the exception of the '/serial' slash command (see "SOA" above),
480 can only be placed where the name for a record would be placed. Like
481 resource records, a tilde is to be placed after the slash command.
482 Note also that slash commands are case-sensitive, and the command in
483 question must be in all-lower-case.
484 These commands are as follows:
486 Default TTL
488 The default TTL is the TTL for a resource record without a TTL
490 specified. This can be changed with the '/ttl' slash command. This
491 command takes only a single argument: The time, in seconds, for the new
492 default TTL. The '/ttl' slash command only affects the TTL of records
493 that follow the command. A zone file can have multiple '/ttl' slash
494 commands.
495 The default TTL is 86400 seconds (one day) until changed by the '/ttl'
497 slash command.
498 In the following example, a.ttl.example.com will have a TTL of 86400
500 seconds (as long as the zone file with this record has not previously
501 used the '/ttl' slash command), b.ttl.example.com and d.ttl.example.com
502 will have a TTL of 3600 seconds, c.ttl.example.com will have a TTL of
503 9600 seconds, and e.ttl.example.com will have a TTL of 7200 seconds:
504 a.ttl.example.com. 10.0.0.1 ~
506 /ttl 3600 ~
507 b.ttl.example.com. 10.0.0.2 ~
508 c.ttl.example.com. +9600 10.0.0.3 ~
509 d.ttl.example.com. 10.0.0.4 ~
510 /ttl 7200 ~
511 e.ttl.example.com. 10.0.0.5 ~
512 Origin
514 It is possible to change the host name suffix that is used to
516 substitute the percent in a csv2 zone file. This suffix is called, for
517 historical and compatibility reasons, "origin". This is done as the
518 slash command '/origin', taking the new origin as the one argument to
519 this function. Note that changing the origin does not change the domain
520 suffix used to determine whether a given domain name is authoritative.
521 Here is one example usage of the '/origin' slash command:
523 /origin example.com. ~
525 www.% 10.1.0.1 ~
526 % MX 10 mail.% ~
527 mail.% 10.1.0.2 ~
528 /origin example.org. ~
529 www.% 10.2.0.1 ~
530 % MX 10 mail.% ~
531 mail.% 10.2.0.2 ~
532 Which is equivalent to:
534 www.example.com. 10.1.0.1 ~
536 example.com. MX 10 mail.example.com. ~
537 mail.example.com. 10.1.0.2 ~
538 www.example.org. 10.2.0.1 ~
539 example.org. MX 10 mail.example.org. ~
540 mail.example.org. 10.2.0.2 ~
541 It is also possible to make the current origin be part of the new
543 origin:
544 /origin example.com. ~
546 % 10.3.2.1 ~ # example.com now has IP 10.3.2.1
547 /origin mail.% ~
548 % 10.3.2.2 ~ # mail.example.com now has IP 10.3.2.2
549 Opush and Opop
551 The '/opush' and '/opop' slash commands use a stack to remember and
553 later recall values for the origin (see origin above). The '/opush'
554 command is used just like the '/origin' command; however, the current
555 origin is placed on a stack instead of discarded. The '/opop' command
556 removes ("pops") the top element from this stack and makes the element
557 the origin.
558 For example:
560 /origin example.com. ~
562 /opush mail.% ~ # origin is now mail.example.com; example.com is on stack
563 a.% 10.4.0.1 ~ # a.mail.example.com has IP 10.4.0.1
564 /opush web.example.com. ~ # mail.example.com and example.com are on stack
565 a.% 10.5.0.1 ~ # a.web.example.com has IP 10.5.0.1
566 b.% 10.5.0.2 ~ # b.web.example.com has IP 10.5.0.2
567 /opop ~ # origin is now mail.example.com again
568 b.% 10.4.0.2 ~ # b.mail.example.com has IP 10.4.0.2
569 /opop ~ # origin is now example.com
570 % MX 10 a.mail.% ~ # example.com. MX 10 a.mail.example.com.
571 % MX 20 b.mail.% ~ # example.com. MX 20 b.mail.example.com.
572 The opush/opop stack can have up to seven elements on it.
574 Read
576 The '/read' slash commands allows one to have the contents of another
578 file in a zone. The '/read' command takes a single argument: A filename
579 that one wishes to read. The filename is only allowed to have letters,
580 numbers, the '-' character, the '_' character, and the '.' character in
581 it.
582 The file needs to be in the same directory as the zone file. The file
584 will be read with the same privileges as the zone file; content in the
585 file should come from a trusted source or be controlled by the system
586 administrator.
587 Let us suppose that we have the following in a zone file:
589 mail.foo.example.com. 10.3.2.1 ~
591 /read foo ~
592 foo.example.com. MX 10 mail.foo.example.com. ~
593 And a file foo with the following contents:
595 foo.example.com. 10.1.2.3 ~
597 foo.example.com. TXT 'Foomatic!' ~
598 Then foo.example.com will have an A record with the value 10.1.2.3, a
600 TXT value of 'Foomatic!', and a MX record with priority 10 pointing to
601 mail.foo.example.com. mail.foo.example.com will have the IP 10.3.2.1.
602 Note that no pre-processing nor post-processing of the origin is done
604 by the '/read' command; should the file read change the origin, this
605 changed value will affect any records after the '/read' command. For
606 example, let us suppose db.example.com looks like this:
607 /origin foo.example.com. ~
609 % TXT 'Foomatic!' ~
610 /read foo ~
611 % MX 10 mail.foo.example.com. ~
612 And the file foo looks like this:
614 % 10.1.2.3 ~
616 /origin mail.% ~
617 % 10.3.2.1 ~
618 Then the following records will be created:
620 foo.example.com. TXT 'Foomatic!' ~
622 foo.example.com. A 10.1.2.3 ~
623 mail.foo.example.com. A 10.3.2.1 ~
624 mail.foo.example.com. MX 10 mail.foo.example.com. ~
625 To have something that works like '$INCLUDE filename' in a RFC1035
627 master file, do the following:
628 /opush % ~
630 /read filename ~
631 /opop ~
632 Or, for that matter, the equivalent of '$INCLUDE filename neworigin':
634 /opush neworigin. ~
636 /read filename ~
637 /opop ~
638
640 # This is an example csv2 zone file
641 # First of all, csv2 zone files do not need an SOA record; however, if
643 # one is provided, we will make it the SOA record for our zone
644 # The SOA record needs to be the first record in the zone if provided
645 # This is a commented out record and disabled.
646 #% SOA % email@% 1 7200 3600 604800 1800 ~
648 # Second of all, csv2 zone files do not need authoritative NS records.
650 # If they aren't there, MaraDNS will synthesize them, based on the IP
651 # addresses MaraDNS is bound to. (She's pretty smart about this; if
652 # Mara is bound to both public and private IPs, only the public IPs will
653 # be synthesized as NS records)
654 #% NS a.% ~
656 #% NS b.% ~
657 # Here are some A (ipv4 address) records; since this is the most
659 # common field, the zone file format allows a compact representation
660 # of it.
661 a.example.net. 10.10.10.10 ~
662 # Here, you can see that a single name, "b.example.net." has multiple IPs
663 # This can be used as a primitive form of load balancing; MaraDNS will
664 # rotate the IPs so that first IP seen by a DNS client changes every time
665 # a query for "b.example.net." is made
666 b.example.net. 10.10.10.11 ~
667 b.example.net. 10.10.10.12 ~
668 # We can have the label in either case; it makes no difference
670 Z.EXAMPLE.NET. 10.2.3.4 ~
671 Y.EXAMPLE.net. 10.3.4.5 ~
672 # We can use the percent shortcut. When the percent shortcut is present,
674 # it indicates that the name in question should terminate with the name
675 # of the zone we are processing.
676 percent.% a 10.9.8.7 ~
677 # And we can have star records
679 #*.example.net. A 10.11.12.13 ~
680 # We can have a ttl in a record; however the ttl needs a '+' before it:
682 # Note that the ttl has to be in seconds, and is before the RTYPE
683 d.example.net. +86400 A 10.11.12.13 ~
684 f.example.net. # As you can see, records can span multiple lines
686 A 10.2.19.83 ~
687 # This allows well-commented records, like this:
689 c.example.net. # Our C class machine
690 +86400 # This record is stored for one day
691 A # A record
692 10.1.1.1 # Where we are
693 ~ # End of record
694 # We can even have something similar to csv1 if we want...
696 e.example.net.|+86400|a|10.2.3.4|~
697 h.example.net.|a|10.9.8.7|~
698 # Here, we see we can specify the ttl but not the rtype if desired
699 g.example.net.|+86400|10.11.9.8|~
700 # Here is a MX record
702 # Note that "IN" is a pseudo-RR which means to ignore the RR type and
703 # look at the next RR type in the zone file; this allows MaraDNS zone
704 # files to look more like BIND zone files.
705 % mx 10 mail.% ~
706 mail.% +86400 IN A 10.22.23.24 ~
707 # We even have a bit of ipv6 support
709 a.example.net. aaaa 2001:db8:1:2::3:f ~
710 # Not to mention support for SRV records
712 _http._tcp.% srv 0 0 80 a.% ~
713 # TXT records, naturally
715 example.net. txt 'This is some text' ~
716 # Starting with MaraDNS 1.2.08, there is also support for SPF records,
718 # which are identical to TXT records. See RFC4408 for more details.
719 example.net. spf 'v=spf1 +mx a:colo.example.com/28 -all' ~
720
723 THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR
724 IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
725 WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
726 DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR
727 ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
728 DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
729 OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
730 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
731 STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
732 IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
733 POSSIBILITY OF SUCH DAMAGE.
734
736 Sam Trenholme http://www.samiam.org/
737MARADNS January 2007 CSV2(5)