242
CNAME records are not permitted in a csv2_default_zonefile.
255
CNAME records are not permitted in a csv2_default_zonefile. If you
256
do not know what a csv2_default_zonefile is, this fact is of no
259
<h1>Historical and uncommon resource records</h1>
261
The following resource records are mainly of historical interest, or
262
are not commonly used.
266
An HINFO record is a description of the CPU (processor) and OS that
267
a given host is using. The format for this record is identical to a
268
TXT record, except that the field must have precisely two chunks.
272
The first chunk of a HINFO record is the CPU the host is running; the
273
second chunk is the OS the host is running.
280
example.com. HINFO 'Intel Pentium III';'CentOS Linux 3.7'
283
This resource record is not actively used--the IANA
284
has a list of CPUs and OSes that this record is supposed to have. However,
285
this list has not been updated since 2002.
289
WKS records are historical records which have been superseded by SRV
290
records. The format of the record is an IP, followed by a protocol
291
number (6 means TCP), followed by a list of ports that a given server
292
has available for services.
296
For example, to advertise that example.net has the IP 10.1.2.3, and has a
297
SSH, HTTP (web), and NNTP server:
300
example.net. WKS 10.1.2.3 6 22,80,119
303
MaraDNS only allows up to 10 different port numbers in a WKS record,
304
and requires that the listed port numbers are not be higher than 1023.
308
MD and MF records are RR types that existed before MX records, and were
309
made obsolete by MX records. RFC1035 says that a DNS server can either
310
reject these records or convert these records in to MX records. BIND
311
rejects these records; MaraDNS converts them.
318
example.net. MD a.example.net.
319
example.net. MF b.example.net.
325
example.net. MX 0 a.example.net.
326
example.net. MX 10 b.example.net.
329
<h2>MB, MG, MINFO, and MR</h2>
331
In the late 1980s, an alternative to MX records was proposed. This
332
alternative utilized MB, MG, MINFO, and MR records. This alternative
333
failed to gather popularity. However, these records were codified in
334
RFC1035, and are supported by MaraDNS. Here is what the records look
338
example.net. MB mail.example.net.
339
example.net. MG mg@example.net.
340
example.net. MINFO rm@example.net. re@example.net.
341
example.net. MR mr@example.net.
344
More information about these records can be found in RFC1035.
346
<h2>AFSDB, RP, X25, ISDN, and RT</h2>
348
AFSDB, RP, X25, ISDN, and RT are resource records which were
349
proposed in RFC1183. None of these resource records are widely
354
With the exception of the ISDN record, the format of these records
355
is identical to the examples in RFC1183. The format of the ISDN
356
record is identical unless the record has a subaddress (SA). If
357
an ISDN record has a subaddress, it is separated from the ISDN-address
358
by a ';' instead of whitespace.
362
If used, here is how the records would look in a csv2 zone file:
365
example.net. AFSDB 1 afsdb.example.net.
366
example.net. RP rp@example.net. rp.example.net.
367
example.net. RP rp2@example.net. .
368
example.net. X25 311061700956
369
example.net. ISDN 150862028003217
370
example.net. ISDN 150862028003217;004
371
example.net. RT 10 relay.example.net.
374
<h2>NSAP and NSAP-PTR</h2>
376
NSAP and NSAP-PTR records were proposed in RFC1706. A NSAP record is
377
a hexadecimal number preceeded by the string "0x" and with optional dots
378
between bytes. This hexadecimal number is converted in to a binary number
379
by MaraDNS. A NSAP-PTR record is idenical to a PTR record, but has a
384
More information about these records can be obtained from RFC1706.
388
If used, here is how the records would look in a csv2 zone file:
391
example.net. NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
392
example.net. NSAP-PTR nsap.example.net.
397
The PX RR is an obscure RR described in RFC2163. A PX record looks like
398
this in a CSV2 zone file:
401
example.net. PX 15 px1.example.net. px2.example.net.
406
An GPOS record is a description of the location of a given server.
407
The format for this record is identical to a
408
TXT record, except that the field must have precisely three chunks.
412
The first chunk of a GPOS record is the longitude; the second chunk is
413
the latitude; the third chunk is the altitude (in meters).
420
example.net. GPOS '-98.6502';'19.283';'2134'
423
More information about this record can be found in RFC1712.
427
This resource record is not actively used; for the relatively few people
428
who encode their position in DNS, the LOC record is far more common.
432
The LOC recource record is an uncommonly used resource record that
433
describes the position of a given server. LOC records are described
438
Note that MaraDNS' LOC parser assumes that the altitude,
439
size, horizontal, and vertical precision numbers are always expressed
440
in meters. Also note that that sub-meter values for size, horizontal, and
441
vertical precision are not allowed. Additionally, the altitude can not
442
be greater than 21374836.47 meters.
449
example.net. LOC 19 31 2.123 N 98 3 4 W 2000m 2m 4m 567m
452
<h1>SLASH COMMANDS</h1>
454
In addition to being able to have resource records and comments, csv2
455
zone files can also have special slash commands. These slash commands,
456
with the exception of the '/serial' slash command (see "SOA" above),
457
can only be placed where the name for a record would be placed.
458
Note that slash commands are case-sensitive, and the command in
459
question must be in all-lower-case.
463
These commands are as follows:
467
The default TTL is the TTL for a resource record without a TTL specified.
468
This can be changed with the '/ttl' slash command. This command
469
takes only a single argument: The time, in seconds, for the new default TTL.
470
The '/ttl' slash command only affects the TTL of records that follow the
471
command. A zone file can have multiple '/ttl' slash commands.
475
The default TTL is 86400 seconds (one day) until changed by the '/ttl'
480
In the following example, a.ttl.example.com will have a TTL of 86400
481
seconds (as long as the zone file with this record has not previously used
482
the '/ttl' slash command), b.ttl.example.com and d.ttl.example.com will
483
have a TTL of 3600 seconds, c.ttl.example.com will have a TTL of 9600
484
seconds, and e.ttl.example.com will have a TTL of 7200 seconds:
487
a.ttl.example.com. 10.0.0.1
489
b.ttl.example.com. 10.0.0.2
490
c.ttl.example.com. +9600 10.0.0.3
491
d.ttl.example.com. 10.0.0.4
493
e.ttl.example.com. 10.0.0.5
498
It is possible to change the host name suffix that is used to substitute the
499
percent in a csv2 zone file. This suffix is called, for historical and
500
compatibility reasons, "origin". This is done as the slash command
501
'/origin', taking the new origin as the one argument to this function.
502
Note that changing the origin does <i>not</i> change the domain suffix
503
used to determine whether a given domain name is authoritative.
507
Here is one example usage of the '/origin' slash command:
520
Which is equivalent to:
523
www.example.com. 10.1.0.1
524
example.com. MX 10 mail.example.com.
525
mail.example.com. 10.1.0.2
526
www.example.org. 10.2.0.1
527
example.org. MX 10 mail.example.org.
528
mail.example.org. 10.2.0.2
531
It is also possible to make the current origin be part of the new origin:
535
% 10.3.2.1 # example.com now has IP 10.3.2.1
537
% 10.3.2.2 # mail.example.com now has IP 10.3.2.2
540
<h2>Opush and Opop</h2>
542
The '/opush' and '/opop' slash commands use a stack to remember and later
543
recall values for the origin (see origin above). The '/opush' command
544
is used just like the '/origin' command; however, the current origin is
545
placed on a stack instead of discarded. The '/opop' command removes
546
("pops") the top element from this stack and makes the element the origin.
554
/opush mail.% # origin is now mail.example.com; example.com is on stack
555
a.% 10.4.0.1 # a.mail.example.com has IP 10.4.0.1
556
/opush web.example.com. # mail.example.com and example.com are on stack
557
a.% 10.5.0.1 # a.web.example.com has IP 10.5.0.1
558
b.% 10.5.0.2 # b.web.example.com has IP 10.5.0.2
559
/opop # origin is now mail.example.com again
560
b.% 10.4.0.2 # b.mail.example.com has IP 10.4.0.2
561
/opop # origin is now example.com
562
% MX 10 a.mail.% # example.com. MX 10 a.mail.example.com.
563
% MX 20 b.mail.% # example.com. MX 20 b.mail.example.com.
566
The opush/opop stack can have up to seven elements on it.
570
The '/read' slash commands allows one to have the contents of another
571
file in a zone. The '/read' command takes a single argument: A filename
572
that one wishes to read. The filename is only allowed to have letters,
573
numbers, the '-' character, the '_' character, and the '.' character in it.
577
The file needs to be in the same directory as the zone file. The file will
578
be read with the same privileges as the zone file; content in the file
579
should come from a trusted source or be controlled by the system
584
Let us suppose that we have the following in a zone file:
587
mail.foo.example.com. 10.3.2.1
589
foo.example.com. MX 10 mail.foo.example.com.
592
And a file foo with the following contents:
595
foo.example.com. 10.1.2.3
596
foo.example.com. TXT 'Foomatic!'
599
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.
605
Note that no pre-processing nor post-processing of the origin is done
606
by the '/read' command; should the file read change the origin, this
607
changed value will affect any records after the '/read' command. For
608
example, let us suppose db.example.com looks like this:
611
/origin foo.example.com.
614
% MX 10 mail.foo.example.com.
617
And the file foo looks like this:
625
Then the following records will be created:
628
foo.example.com. TXT 'Foomatic!'
629
foo.example.com. A 10.1.2.3
630
mail.foo.example.com. A 10.3.2.1
631
mail.foo.example.com. MX 10 mail.foo.example.com.
634
To have something that works like '$INCLUDE filename' in a RFC1035
635
master file, do the following:
643
Or, for that matter, the equivalent of '$INCLUDE filename neworigin':
244
651
<h1>EXAMPLE ZONE FILE</h1>
added
removed
doc/en/source/csv2.ej
