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

NAME

6       csv1 - Format of the csv1 zone file that MaraDNS uses
7

SPECIAL NOTE

9       The csv1 zone file format is supported primarily for MaraDNS users who
10       already have zone files in the csv1 format. MaraDNS now supports a csv2
11       zone file format. Note that the csv1 zone file format will continue to
12       function as long as I am MaraDNS' maintainer.
13

SPECIAL CHARACTERS

15       |  This delimits fields
16
17       #  This signifies a comment. Lines starting with this are ignored,
18          otherwise it has no significance
19
20       %  This, in domain names, signifies that the rest of the domain name
21          should be the name of this zone
22
23       *  This is translated to mean "any host name that otherwise does not
24          resolve". It must be at the beginning of a domain name.
25
26       \  This is used as an escape character, either to escape octal values
27          such as '\045' for %, or to escape the '%' character so it has no
28          special meaning, or to escape the backslash character.
29

NOTES ON PROCESSING

31       All domain-name labels are converted to their lower-case equivalents
32       before processing is done. This is because domain-name literals in the
33       database with one or more upper-case letters in them are case-
34       sensitive. This is my way to resolve RFC1035's desire to both allow
35       binary domain labels and be case-insensitive.
36
37       The file must first have a SOA record, followed by one or more NS
38       records, followed by other records. The initial NS and SOA records must
39       be RR for this zone. NS records after any non-NS record must be part of
40       another zone. The resolution algorithm will not break if non-CNAME
41       records share records with a CNAME record, but this is not a good idea
42       to do.
43

RR FORMAT

45       A domain name is a one-letter designation of its type, followed by the
46       domain name separated by dots, ending with either a % or a trailing
47       dot. If the domain name does not end with a % or trailing dot, an error
48       is returned.
49

SUPPORTED RR TYPES

51       MaraDNS only supports the following types of resource records (RRs) in
52       csv1 files. More resource records types are supported in csv2 zone
53       files; see csv2(5) for details.
54
55       Letter  Type    RFC1035 section 3.2.2 value
56       A       A       1
57       N       NS      2
58       C       CNAME   5
59       S       SOA     6
60       P       PTR     12
61       @       MX      15
62       T       TXT     16
63       U       any     determined in third field of line
64
65

FORMAT OF SUPPORTED RR TYPES

67       Here are the formats, shown by letter name:
68
69       A: Has three fields
70       field one: the domain name
71       field two: the ttl for the name in seconds
72       field three: the ip address, in dotted decimal notation
73       Example:
74       Ahost.example.com.|7200|10.1.2.3
75
76       A records are described with grueling detail in RFC1035. In short, an A
77       record is an IP address for a given host name.
78
79       N: Has three fields
80       field one: the domain name of the record
81       field two: the ttl for the name in seconds
82       field three: the domain name this NS points to.
83       Example:
84       Nexample.com.|86400|ns.example.com.
85
86       NS (N here) records are described in RFC1035
87
88       C: Has three fields
89       field one: the domain name of the record
90       field two: the ttl for the name in seconds
91       field three: the domain this CNAME record points to
92       Example:
93       Calias.example.org.|3200|realname.example.org.
94
95       CNAME (which C is short for) records are described in RFC1035
96
97       S: Has nine fields
98       field one: the domain name of the record
99       field two: the TTL of the record
100       field three: the origin of the domain.  In other words, the name of the
101                    primary name server for the domain.
102       field four: the email address for this domain (in the RFC822, not
103                   BIND format)
104       field five: the serial for the domain
105       field six: the refresh (how often to see updates) for the domain
106       field seven: the retry (how often to try when down) for the domain
107       field eight: the expire (how long before the slave gives up) for the
108                    domain
109       field nine: the minimum (and default) TTL for the domain
110       Example:
111       Sexample.net.|86400|%|hostmaster@%|19771108|7200|3600|604800|1800
112
113       SOA (S here) records are described in RFC1035
114
115       P: has three fields
116       field one: the IP we wish to point to (in in-addr.arpa form)
117       field two: the ttl for the name in seconds
118       field three: the FQDN for the IP in question
119       Example:
120       P3.2.1.10.in-addr.arpa.|86400|ns.example.com.
121
122       PTR (P here) records, which are used for reverse DNS lookups, are
123       described in RFC1035. Note that one needs control of the appropriate
124       in-addr.arpa subdomain to make PTR records visible on the internet at
125       large.
126
127       @: has four fields
128       field one: The host that people send email to
129       field two: the ttl for this record
130       field three: The preference for this MX host
131       field four: The name of this MX host
132       Example:
133       @example.com.|86400|10|mail.example.com.
134
135       MX (@ here) records are described in RFC1035
136
137       T: has three fields
138       field one: The host someone wants to get additional information about
139       field two: the ttl for this record
140       field three: The desired text.  Any data becomes the record up until a
141                    new line is reached.  The new line is not part of the TXT
142                    record
143       Example:
144       Texample.com.|86400|Example.com: Buy example products online
145
146       TXT (T here) records are described in RFC1035
147
148       U: has four fields
149       field one: The host someone wants a data type normally unsupported by
150                  MaraDNS for
151       field two: the ttl for this record
152       field three: The numeric code for this data type (33 for SRV, etc.)
153       field four: The raw binary data for this data type
154       Example:
155       Uexample.com.|3600|40|\010\001\002Kitchen sink data
156
157       The above example is a "Kitchen Sink" RR (see draft-ietf-dnsind-
158       kitchen-sink-02.txt) with a "meaning" of 8, a "coding" of 1, a
159       "subcoding" of 2, and a data string of "Kitchen sink data". Since this
160       particular data type is not formalized in a RFC at this time, the most
161       appropriate method of storing this data is by using the catch-all
162       "unsupported" syntax.
163

EXAMPLE CSV1 ZONE FILE

165       # Example CSV1 zone file
166
167       # This is what is known as a SOA record.  All zone files need to have one
168       # of these
169       S%|86400|%|hostmaster@%|19771108|7200|3600|604800|1800
170       # These are known as authoritative NS records.  All zone files need one or
171       # more of these
172       N%|86400|ns1.%
173       N%|86400|ns2.%
174
175       # Some IP addresses
176       Ans1.%|86400|10.0.0.1
177       Ans2.%|86400|192.168.0.1
178       A%|86400|10.1.2.3
179       Amx.%|86400|10.1.2.4
180
181       # An 'IN MX' record
182       @%|86400|10|mx.%
183
184
186       THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR
187       IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
188       WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
189       DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR
190       ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
191       DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
192       OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
193       HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
194       STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
195       IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
196       POSSIBILITY OF SUCH DAMAGE.
197

AUTHOR

199       Sam Trenholme http://www.samiam.org/
200
201
202
203
204MARADNS                          January 2002                          CSV1(5)
Impressum