1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
|
$Id: REQUIREMENTS 2972 2010-02-24 10:54:20Z matje $
NSD Requirements and Specifications
______________________________________________________________________
A. Scope.
NSD is a complete implementation of an authoritative DNS
nameserver. This document describes the basic requirements and
specifications for this implementation.
B. Requirements
B.1. General Requirements
These requirements are in order of importance:
1. Conformity to the relevant DNS RFCs
If complying with the letter of the RFCs will cause a conflict with
high load resilience reasoned trade-offs will be made and
documented.
2 Code diversity from other implementations
NSD is developed from scratch and does not share code or design
with other implementations.
3. Authoritative server only
NSD is designed to provide authoritative answers only. There are
no facilities for caching or recursion.
4. Open source
The code will be open source after the first public release.
5. Regression tested against bind8/9
Extensive regression tests with real trace data and synthetic
exceptional data will be carried out. For the real traces any
differences with bind8/9 will be documented. Should there be
substantial differences a bind8/9 compatibility option will be
considered. The testing tools will be published separately as much
as possible.
6. Resilience to high load
As many as UDP queries answered as possible per time interval.
Aware of useless queries and limiting answers to conserve output
bandwidth. This may supersede strict RFC compliance. Mitigation of
DDoS attacks as far as feasible.
7. Documentation
The implementation will be well documented with the aim of allowing
others to understand its operation in order to be able to maintain
the code. This includes these requirements, a general design
document and well documented code.
8. Reviewed code
All code will be reviewed by at least two persons other than the
primary author before being included in a release version.
9. Simplicity
NSD will not do things that are not strictly necessary for its
task: authoritative name serving. If in doubt a feature is more
likely not to be included.
The code strives to be as simple and straightforward as possible,
even if it looks stupid ;-).
10. Reasonable Portability
Should be reasonably portable across hardware architectures and OS
platforms. Rough targets:
(Intel/SPARC/Alpha)(FreeBSD,Linux,Solaris)
11. Maintenance for initial period
NLnet Labs and the RIPE NCC will support NSD for at least 12
months after publication.
B.2. Explicit NON-Requirements
1. No caching
NSD will not provide cached or recursive answers.
2. No slavish responsiveness
NSD may decide to limit answers to queries it considers malicious
or useless if this enables it to provide better service to queries
it considers valid. Conserving output bandwidth is a consideration.
3. No end-user friendliness
NSD operators are considered to have basic Unix and networking
knowledge and are also considered to be able to read and understand
reasonably written user documentation.
4. No creeping featurism
NSD will not implement any functionality that is not strictly
necessary for the task of authoritative name serving. Examples:
round robin sequence of RRset members in consecutive answers,
Also no dynamic plugins.
C. Technical Specification.
C.0 Environment
The server runs with the least possible permissions.
NSD will not implement special VM work-arounds to accommodate zones
larger than order 10 million RRs in 32-bit address space machines.
Operators requiring huge-zone support can use 64-bit machines.
C.1. Zone file format and RR records.
Zone file format as specified in rfc1035 (5.1), including the $TTL
entry for default TTL as in RFC2308 (4) and the binary label format
as in RFC2673.
We implement most RRs currently assigned by IANA
(http://www.iana.org/assignments/dns-parameters) except for RRs
that are obsoleted by IANA or assigned experimental, those MAY not
be implemented. See below and/or release notes.
Zone file MUST not contain errors. i.e. the zonecompiler may fail
or produce unpredictable results when:
- RRs that are obsolete and not implemented are encountered.
- Syntax errors are found (RFC1035 5.2)
+ not all RRs are of the same zone
+ not exactly one SOA RR is present at the top of the zone.
+ delegations are present but required glue is not present.
+ Out of Zone, non-glue data is encountered.
+ not all RRs in a RRset have the same TTL (RFC2181 5.2)
+ if a DNAME exists at node N there may not be any other data
at 'N' (except CNAME or DNAME) and there MUST not be any
other data at subnodes of 'N' (RFC 2672 section 3).
- The default minimum TTL is not specified by the $TTL directive
Zones that are parsed by the zonecompiler will be served by the nsd
daemon.
Only zone files of CLASS "IN" are supported.
The zone file parser sets the TTL of those RRs that do not have
their TTL defined to the minimum TTL as defined by the $TTL
directive unless the RR is part of a RRset and the TTL is set for
one of the RRs in the RRset.
Parsing of the names in zone files is case insensitive
(Note: RFC1035 2.3.3 also see 1034 3.1
"The basic rule is that case can be discarded only when data is
used to define structure in a database, and two names are
identical when compared in a case insensitive manner."
)
The database relies on case; all names will be parsed to lower
case. Case of dnames in RDATA will be preserved except for dnames
for which dname compression in RDATA is allowed, those dname fields
are converted to lower case. (for that subset of RRs compression
has preference over case preservation). Also see Appendix B for
dname compression in RDATA.
DNSSEC consideration (as of 2.0.0):
DNSSEC processing of data in a zone will only take place if that
zone is marked to be secure. A zone is marked secure if the SOA
record is signed. The zone data is not cryptographically checked at
the time the zone db is generated;
NSD always clears the AD flag on answering data from a secure zone
in the database.
NSD always copies the CD bit from the query to the response.
NSD does not include the DNSKEY RRset in the additional section on
queries for the SOA or NS records at the zone apex. It is not
clear whether including the DNSKEY RRset is advantageous and not
doing so simplifies NSD.
C.2. Server and connection management.
The server listens on port 53. The server answers with the same IP
address and port (53) as the queries has been sent to. Replies are
sent to the address/port the queries originated from. (rfc 2181 4)
UDP.
The server is optimized to handle UDP queries. Large packet sizes
are supported. The size is set by the OS
(e.g. net.inet.udp.maxdgram on FreeBSD).
TCP.
The server accepts TCP connections.
Note that there may be one or more DNS messages in the stream. Each
message is prepended with a 2 byte size (rfc 1035 4.2.2)
Connection management (rfc1035 4.2.2.)
+ the server should not block other activities waiting for TCP data
+ The server should assume that the client will initiate
connection closing and should delay closing its end of the
connection until all outstanding client requests have been
satisfied.
+ For closing dormant connections the timeout should be in the
order of 2 minutes.
NSD specific:
+ The maximum number of open TCP connections is configurable.
It is assumed the OS copes with attacks on the TCP stack (e.g
like SYN attacks)
C.3 Incoming DNS Message processing.
NSD specific choices.
These issues are not addressed in the RFCs. Behavior is defined below.
+ Non parsable messages are replied to with a FORMERR.
+ Each UDP packet only carries one DNS Message. Any data behind
the DNS message is considered garbage and is ignored.
+ Incoming DNS messages with the QR bit set to 1 (response) are
discarded. (In spirit of rfc 1035 sect 7.3)
+ RD is copied into the response (rfc 1035 4.1.1) the RA bit is
set to 0 and the QUERYID is copied into the response message.
+ OPCODE 0 (QUERY) results in normal handling
of packet (rfc1035)
OPCODE 1 (IQUERY) results in RCODE=4 NOTIMPL (rfc1035)
OPCODE 2 (STATUS) results in RCODE=4 NOTIMPL (rfc1035)
OPCODE 3 (RESERVED) results in RCODE=4 NOTIMPL
OPCODE 4 (NOTIFY) results in RCODE=4 access control list
processing and then handling of the notify. (rfc1995)
OPCODE 5 (UPDATE) results in RCODE=4 NOTIMPL (rfc2136 sect 3)
+ AA bit in query packet is ignored.
+ TC bit set in a query packet is answered with FORMERR.
[This must always be a broken implementation since the max
length of the name is 255 octets.]
+ RCODES are ignored.
+ QDCOUNT=1 results in further processing.
QDCOUNT!=1 results in RCODE=1 FORMERR
+ QCLASS=IN results in further processing.
+ QCLASS=ANY results in further processing with the AA bit in the
response off (rfc 1035 6.2)
+ QLASS=CHAOS only leads to further processing if the queries are
for the names ID.SERVER or VERSION.SERVER. Any other query in that
namespace will lead to RCODE=REFUSED.
For QTYPE other than TXT a NOERROR with a trivial SOA RR in the
AUTHORITY section will be returned.
Behavior for QTYPE=TXT is defined in draft-ietf-dnsop-serverid-00.txt
+ QCLASS!=IN && QCLASS!=ANY && QCLASS!=CHAOS results in RCODE=REFUSED
[Background: BIND8 generates a SERVFAIL but I would say that a A
NOERROR message with empty Answer, Authority and
Additional section is also a good answer and more in the
spirit of RFC 1034 section 4.3.1.
We choose to mimic the behavior of bind.
BIND9 generates a status RCODE=5 REFUSED.
]
+ Other sections should be empty otherwise FORMERR.
+ except, EDNS and TSIG opt records are allowed.
+ TSIG signature is checked, otherwise a TSIG error.
+ Presence of OPT RR indicates support of EDNS (rfc2671). If the
VERSION > 0 then the server will respond with an OPT with
RCODE=BADVERSION and VERSION=0 (The server supports EDNS0) In
further processing ENDS0 support is taken into account.
+ If the DNSSEC OK bit (DO bit) is set then the query will be
processed as a DNSSEC request. Although RFC3225 does not
explicitly specify this NSD clears the DO bit in the answer.
C 4 Further Query processing.
Preconditions:
+ the QCLASS is either IN or ANY. For both classes the IN class
zones are searched in the same manner. The difference in the
response will be in the Authority information.
+ It is known if the requester supports EDNS0
+ There is only one query in the DNS message to be answered.
+ The RD & message ID of the incoming query has been copied into
the response message.
+ It is known if the requester wants DNSSEC processing as indicated by
the DO bit being set.
C 4.1 Actions based on QTYPE of incoming Query.
If QTYPE>=249 we are dealing with special queries.
case QTYPE=TKEY
case QTYPE=TSIG
case QTYPE=IXFR respond with RCODE=5 (REFUSED)
case QTYPE=AXFR respond with AXFR (TSIG is supported)
case QTYPE=MAILB proceed with processing.
case QTYPE=MAILA proceed with processing.
case QTYPE=ANY proceed with processing.
QTYPE < 249 process the query
Further processing of the packet is based on the algorithm from
1034 as modified by (rfc2672 4). Below is the algorithm as applies
to an authoritative cache-less server and with the preconditions from
above. We have also included DNSSEC considerations (rfc2535 and
rfc3225)
The first versions of NSD will not have DNSSEC processing
implemented. (Read this as the DO bit is not set).
1. Search the available zones for the zone which is the nearest
ancestor to QNAME. If such a zone is found, go to step 2,
otherwise step 3.
2. Start matching down, label by label, in the zone. The matching
process can terminate several ways:
a. If the whole of QNAME is matched, we have found the node.
If the data at the node is a CNAME, and QTYPE doesn't match
CNAME, copy the CNAME RR into the answer section of the
response, change QNAME to the canonical name in the CNAME RR,
and go back to step 1. If the DO bit is set in the query the
RRSIG(CNAME) needs to be copied in the answer section as well.
Otherwise, copy all RRs which match QTYPE into the answer
section.
Also copy corresponding RRSIGs into the answer section
if the DO bit was set, goto step 4.
If QTYPE is 'ANY' copy all RRs including the security related
RR types regardless if the DO bit was set into the answer section.
If none of the RRtypes matched QTYPE, the DO bit was set and the
zone is marked secure then the answer section is left empty and
b. If a match would take us out of the authoritative data, we have
a referral. This happens when we encounter a node with NS RRs
marking cuts along the bottom of a zone.
Copy the NS RRs for the subzone into the authority section of
the reply.
If the DO bit has been set then
if the zone is marked secure then
if there is a NSEC record or DS record then
include the DS bit and associated RRSIG(DS) into the
authority section if the DS record is present for this
delegation. If there is no DS record present for this
delegation then include the NSEC record with the
corresponding RRSIG(NSEC) in the authority section.
else
we are in an opt-in part of the zone and we should
include the the NSEC RR of the last secured RR in the
zone and the corresponding RRSIG(NSEC) into the authority
section of the answer.
fi
fi
Put whatever addresses are available into the
additional section, using glue RRs if the addresses are not
available from authoritative data. If the DO bit was set then
also copy the RRSIGs for the addresses for which the server is
authoritative.
Go to step 4.
c. If at some label, a match is impossible (i.e., the
corresponding label does not exist), look to see whether the
last label matched has a DNAME record.
BEGIN DNAME (supported as of NSD 3.0)
If a DNAME record exists at that point, copy that record into
the answer section, if the DO bit is set also copy the RRSIG.
If substitution of its <target> for its <owner> in
QNAME would overflow the legal size for a
<domain-name>, set RCODE to YXDOMAIN [DNSUPD] and
exit; otherwise perform the substitution and
continue. If the query was not extended [EDNS0]
with a Version indicating understanding of the DNAME
record, the server SHOULD synthesize a CNAME record
as described above and include it in the answer
section. Go back to step 1. Note that there should
be no descendants of a DNAME in the same zone
(rfc2672 3). So if a DNAME has been found only go to
step 1 if another zone can be found.
NSD will refuse to zonecompile a zone that has descendants
of a DNAME. It always synthesizes CNAME records.
END DNAME
If there was no DNAME record, look to see if the "*" label
exists.
If the "*" label does not exist, check whether the name we
are looking for is the original QNAME in the query or a name
we have followed due to a CNAME. If the name is original,
set an authoritative name error (RCODE=3 NXDOMAIN) in the
response, if the DO bit was set then include the appropriate
NSEC records (see section 4.5.) in the authority section,
then exit.
If the "*" label does exist, match RRs at that node against
QTYPE. If any match, copy them into the answer section, but
set the owner of the RR to be QNAME, and not the node with
the "*" label. If the DO bit is set copy the RRSIG for the *
label and matching QTYPE also set the owner of the RRSIG RR to
be QNAME). In addition a NSEC record indicating that no
specific matches are possible should be returned in the
additional section.
Otherwise just exit.
Go to step 4.
3. If a there was no delegation of authoritative data return the root
delegation in the authority section and continue with 4.
Also see Appendix B.1
4. Using local data only, attempt to add other RRs which may be
useful to the additional section of the query if the DO bit was
set in the query then for retrieval of SOA or NS a DNSKEY of the
same name should be added. For retrieval of type A, AAAA or A6 RRs
the DNSKEY should also be included.
See section 4.2 as well.
Note that on a QNAME match the NS records are not copied into the AUTH
section (This is a requirement from step 4 'matching down the cache'
from rfc1034 4.3.2). This is a requirement only for caching
servers. BIND8 will copy the the NS in the Auth section for
authoritative server too.
C 4.2 Additional Data processing.
Additional data is added as long as there is space in the packet.
When processing the additional section priority is (rfc 2535 3.5 and
rfc 2874 4)
+ A
+ A6
+ AAAA
+ DNSKEY
For truncation see section C.4.4
If the DO bit is set RRSIGs will be included with the additional data.
Although not specified in the RFCs we will assume the following priority:
Note that A glue is always added before any AAAA glue.
+ A
+ RRSIG A
+ A6
+ RRSIG A6
+ AAAA
+ RRSIG AAAA
+ DNSKEY
+ RRSIG DNSKEY
NSD will act as being authoritative for one zone without having the
other zones in cache. In other words:
If a NSD is authoritative for say both ripe.net and nlnetlabs.nl and
both these zones are secondary for each others NS. Then, at least
with my zone parser a query for ripe.net NS would return
ANSWER:
ripe.net NS ns.ripe.net
NS ns.nlnetlabs.nl
Additional
ns.ripe.net A 10.0.0.1
and not
ANSWER:
ripe.net NS ns.ripe.net
NS ns.nlnetlabs.nl
Additional
ns.ripe.net A 10.1.0.1
ns.nlnetlabs.nl A 10.2.0.2
This behavior is a consequence of NSD using precompiled packets. These
are 'constructed' zone by zone. It is an optimisation of speed versus
network optimisation.
In NSD2 and later this behaviour still exists, even though the packets
are constructed at run time, only information from the current zone
is added to a response.
C 4.3 Label compression in RDATA
In the spirit of RFC 1035 section 3.3. and 4.4.1 ("Pointers can
only be used for occurrences of a domain name where the format is not
class specific.") we only do label compression for labels in rdata
for which this is specifically mentioned in the RFC defining the RR.
-NS, SOA, CNAME, and PTR (rfc 1035 3.3)
Others defined in (rfc 1035 3.3) are not compressed.
BIND8 does compression for all RR from rfc 1035 for which dnames
appear in the rdata.
(Note that other RFCs do refer to e.g. MX dname in rdata being
compressed (e.g. rfc2974 4.).
-MB, MG, MR, MINFO, MX also have compressed dnames.
These RRs and their compression are described in RFC 883.
-AFSDB, RP, RT (rfc1183, Section 1,2 & 3.3.3)
The format of these RR does is not CLASS specific so compression
is done for:
dname of the 'hostname' field for AFSDB
dname of the 'mbox-dname' and 'txt-dname' for RP
dname of the 'intermediate-host' for RT.
-NSEC, RRSIG and DNSKEY MUST NOT have dname compression (rfc 4034).
For RRs not mentioned here no label compression in the rdata is
performed.
C 4.4 Truncation handling. (as rfc2181 9)
If inclusion of a RR set that is REQUIRED in either the answer or
authority section leads to message truncation. The section is left
empty and the truncation (TC) bit is set. If the DO bit is set RRSIG
RRs are required in the answer and authority section.
Inclusion of NS RRs in the authority section when QTYPE=DNSKEY is
removed since NSD version 3.2.3. This is to prevent resolvers from
unnecessarily falling back to TCP. Only DNSKEYs are considered,
because it showed that especially these DNS packets are 'troublesome'.
If inclusion of an RRset in the Additional section is not possible
RRs are omitted one by one. This may lead to incomplete RRsets.
Omission of RRs from the Additional section because of message size
constraints will NOT lead to setting of the TC bit. (rfc2181 9) We
allow for incomplete RRsets in the additional section.
C 4.5 NSEC processing.
The NSEC record is required to be in the authority section if a QNAME
or a QTYPE cannot be matched (see section 5 or RFC2535).
If the DO bit on the query is not set then NSEC records should only be
required if QNAME and QTYPE match.
If the do bit on the query is set then we have to do NSEC processing if
a zone is marked as secure otherwise we should do nothing.
If the QNAME matches a name in the zone but the QTYPE does not match
then the answer section should remain empty and the Authority
section should have either the NSEC RR that matches QNAME or the NSEC
RR (opt-in) that indicates QNAME is in an insecure part of the zone.
C 4.6 Timeout management.
NSD manages timeouts on the SOAs for secondary zones according to RFC.
Timeouts are randomized, to avoid network bursts. The randomization
used is 90-100% of the original value - meaning that it can never be
delayed. This means zones cannot expire later than they should.
It does mean the average timeout becomes 95% of the original.
The random number calculation is primitive but fast. It is about spreading
load not about randomness per se (in the crypto sense).
-------------------------------------------------------------------------------
Appendix A
IANA list of RR records
RR records details.
"A" 1, # RFC 1035, Section 3.4.1
No additional processing
"NS" 2, # RFC 1035, Section 3.3.11
Additional A type processing.
dname compression in RDATA
"MD" 3, # RFC 1035, Section 3.3.4 (obsolete)
"MF" 4, # RFC 1035, Section 3.3.5 (obsolete)
"CNAME" 5, # RFC 1035, Section 3.3.1
No additional section processing.
dname compression in RDATA
"SOA" 6, # RFC 1035, Section 3.3.13
No additional section processing.
SOA TTL semantics updated by rfc2308
dname compression in RDATA
"MB" 7, # RFC 1035, Section 3.3.3
Additional processing type A of MADNAME
"MG" 8, # RFC 1035, Section 3.3.6
No additional section processing.
"MR" 9, # RFC 1035, Section 3.3.8
No additional section processing.
"NULL" 10, # RFC 1035, Section 3.3.10
NOT IMPLEMENTED
Not allowed in master files. (Not implemented in BIND)
"WKS" 11, # RFC 1035, Section 3.4.2 (deprecated in favor of MX
[RFC-1123] but not Obsolete)
"PTR" 12, # RFC 1035, Section 3.3.12
No additional section processing.
dname compression in RDATA
"HINFO" 13, # RFC 1035, Section 3.3.2
No additional section processing.
"MINFO" 14, # RFC 1035, Section 3.3.7
No additional section processing.
"MX" 15, # RFC 1035, Section 3.3.9
Additional section processing type A of host in Exchange
"TXT" 16, # RFC 1035, Section 3.3.14
No additional section processing.
"RP" 17, # RFC 1183, Section 2.2
No additional section processing.
"AFSDB" 18, # RFC 1183, Section 1
type A additional section processing for <hostname>
dname compression for hostname
"X25" 19, # RFC 1183, Section 3.1
No additional section processing.
"ISDN" 20, # RFC 1183, Section 3.2
No additional section processing.
"RT" 21, # RFC 1183, Section 3.3
type X25, ISDN, and A additional section processing
for <intermediate-host>.
dname compression for intermediate-host.
"NSAP" 22, # RFC 1706, Section 5
No additional section processing.
NSAP requires special parsing rules.
"NSAP_PTR" 23, # RFC 1348 (obsolete)
"SIG" 24, # RFC 2535, Section
4.1.7: signers name field MAY be compressed.
4.1.8.1: SIG(0) specification.
See section 4.2 for additional section processing.
SIG signers name field MAY be compressed. (2535 4.1.7)
"KEY" 25, # RFC 2535, Section
See section RFC 2535 3.5 on inclusion of keys.
"PX" 26, # RFC 2163,
section 4 says:
PX records cause no additional section processing
All normal DNS conventions, like default values,
wildcards, abbreviations and message
compression, apply also for all the components
of the PX RR.
Compression is not explicitly mentioned:
This label is CLASS specific: NO compression.
"GPOS" 27, # RFC 1712 (obsolete)
"AAAA" 28, # RFC 1886, Section 2.1
"LOC" 29, # RFC 1876
No requirements on additional section processing.
"NXT" 30, # RFC 2535
No requirements on additional section processing.
NXT dname field MAY be compressed. (2535 4.2)
"EID" 31, # draft-ietf-nimrod-dns-xx.txt e.g. http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt
"NIMLOC" 32, # draft-ietf-nimrod-dns-xx.txt e.g. http://ana-3.lcs.mit.edu/~jnc/nimrod/dns.txt
"SRV" 33, # RFC 2782
No dname compression of target field. (rfc2782 page 4)
"ATMA" 34, # [Dobrowski]
"NAPTR" 35, # RFC 2168, 2915
Contains regular expressions. Take care of escaping
backslashes while parsing
(rfc2915 p6): 'Replacement' field: no compression
"KX" 36, # RFC 2230
KX records MUST cause type A additional section
processing for the host specified by EXCHANGER.
In the event that the host processing the DNS
transaction supports IPv6, KX records MUST also
cause type AAAA additional section processing.
The KX RDATA field MUST NOT be compressed.
(rfc2230 section 3)
"CERT" 37, # RFC 2538
No dnames in rdata
"A6" 38, # RFC 2874
No dnames in rdata
"DNAME" 39, # RFC 2672
NO dname compression of target field. (rfc2672 sect 3)
"SINK" 40, # [Eastlake]
"OPT" 41, # RFC 2671
Pseudo RR. Not in zone files.
"APL" 42 # RFC 3123
An APL RR with empty RDATA is valid and implements an empty list.
"DS" 43, # RFC 4033, 4034, 4035.
Included with referrals.
"SSHFP" 44, # SSH Key Fingerprint, RFC 4255
"IPSECKEY" 45, # RFC 4025
Public key RSA/DSA for use in IPSEC.
"RRSIG" 46, # RFC 4033, 4034, 4035. RFC 3755.
Signature, uncompressed dnames.
"NSEC" 47, # RFC 4033, 4034, 4035. RFC 3755.
Signed next ownername, to disprove rrset types and
domain name existance. Uncompressed dnames.
"DNSKEY" 48, # RFC 4033, 4034, 4035. RFC 3755.
Key for zone signing or key signing. Public key part.
"DHCID" 49, # draft-ietf-dnsext-dhcid-rr-13.txt
"NSEC3" 50, # RFC 5155.
Unknown 51 - 98,
"SPF" 99, # RFC 4408 (Experimental).
"UINFO" 100, # [IANA-Reserved]
"UID" 101, # [IANA-Reserved]
"GID" 102, # [IANA-Reserved]
"UNSPEC" 103, # [IANA-Reserved]
"TKEY" 249, # RFC 2930
"TSIG" 250, # RFC 2845
"IXFR" 251, # RFC 1995
"AXFR" 252, # RFC 1035
"MAILB" 253, # RFC 1035 (MB, MG, MR)
"MAILA" 254, # RFC 1035 (obsolete - see MX)
"ANY" 255, # RFC 1035
______________________________________________________________________
Appendix B Details on specific design and implementation choices.
B.1. Returning the root delegation when no answer can be found
From RFC1034/1035 it is not obvious if returning a root delegation
is a (non-)requirement for authoritative servers.
We have decided not to implement a root-hints since an
authoritative server should in normal circumstances only receive
queries for which the server is authoritative.
Also see RFC 1123 section 6.1.2.5.
Whenever an answer cannot been provided we return a SERVFAIL. It
has been argued that this is a policy decision and thus a REFUSE
should be returned. However, in the spirit of RFC1034/1035 a server
should return cached data, if that cache cannot be reached a SERVFAIL
is an appropriate response.
Also see the discussion on the 'namedroppers list' Starting April
2002 with subject "name server without root cache "
(ftp://ops.ietf.org/pub/lists/)
______________________________________________________________________
Appendix C (Planned) Features
NSD Version 1.0.0. and above
The first release ( 1.0.0 ) contains an implementation of the
standard RFC 1034 and RFC 1035, of proposed standards RFC2181
(clarifications), RFC2308 (negative caching).
AXFR is not implemented in v1.0.0.
The RRs specified in the following RFCs are implemented in v1.0.0
- RFC 1183 (Multiple RRs)
- RFC 1706 (NSAP) (Informational)
- RFC 1876 (LOC RR)
- RFC 1886 (AAAA RR)
- RFC 2230 (KX RR) (Informational)
- RFC 2536 (CERT RR)
- RFC 2671 (EDNS0)
- RFC 2782 (SRV)
- RFC 2915 (NAPTR RR)
- RFC 2915 (SRV RR)
- Version 1.0.1 will also support features from
draft-ietf-dnsop-serverid-00.txt: The following names have associated
TXT RRs in the CHAOS class: ID.SERVER. and VERSION.SERVER.
- RFC2535 (DNSSEC) will be implemented in (1.1.0) once the current
drafts DS and OPT-IN have made it to the standards track.
(DNSSEC also includes RFC2536 (DSA), RFC2537 (RSA), RFC3225 (DO
bit)
Version 1.1.0 will not allow wildcards in DNSEC signed zones.
NSD Version 2.0. and above
- AXFR will be implemented in 1.0.1 with simple IP based ACLs. In
1.1.0. AXFR will also supported with RFC 2845 (TSIG)
Using external tool nsd-xfer, that supports TSIG to download
a zone from a server.
- DNSSEC supported RRSIG/NSEC/DNSKEY, RFC 4033, 4034, 4035.
- wildcards allowed in dnssec secured zones.
- RFC 2673 (Binary labels)
- RFC 2874 (A6)
NSD Version 3.0. and above
AXFR: - NSD serves AXFR, with TSIG if needed.
- NSD requests AXFR from xfrd. This is noncompliant with RFC.
It does not ask for the SOA serial number using a query
beforehand (nsd-xfer does). It terminates the AXFR after
the first packet if it determines the AXFR is not needed.
RFC 1996 (NOTIFY):
- will ignore extraneous data in notify (instead of checking
if they differ from content in zone). Only checks SOA serial.
This is too hard, since other information is not available in
xfrd, the process that handles the notify.
- Will not send notify to NS-servers of a zone. Only notify
sent to 'notify:' entries in config file.
- Incoming has an ip-based and key-based access control list.
- can be with TSIG.
RFC 2845 (TSIG):
- TSIG is supported for notify, axfr, ixfr, regular queries.
RFC 2672 (DNAME) support.
RFC 1995 (IXFR) support only for making requests to other servers.
- IXFR is not served.
Secondary zones: - follows SOA timers. (NSD 2 and before did not)
(RFC 1034, 1035).
RFC 4635 (HMAC SHA TSIG) support for mandatory algorithms: hmac-md5,
hmac-sha1, hmac-sha256.
RFC 5001 (NSID) support.
RFC 5155 (NSEC3) support.
Not implemented:
RFC2136 (Dynamic update) are not implemented and will not be implemented as
zone control is not implemented in NSD itself.
Appendix D. Changes to this file.
24 february 2010 (Matthijs Mekking).
- Updated file with RFC 5001 (NSID) and RFC 5155 (NSEC3) support (version
3.0.0 and above).
30 october 2008 (Matthijs Mekking).
- Added support for RFC 4635 (HMAC SHA TSIG).
26 july 2006 (Wouter Wijngaards).
- Comments changed to background items.
- KEY->DNSKEY, SIG->RRSIG in the text, dnssec-bis style.
______________________________________________________________________
$Id: REQUIREMENTS 2972 2010-02-24 10:54:20Z matje $
|
