$Id: REQUIREMENTS,v 1.2 2022/09/24 17:38:17 christos Exp $
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 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 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.
-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. QTYPE=DS followed in version 3.2.7.
This is to prevent resolvers from unnecessarily falling back to TCP.
Only DNSKEY and DS records are considered, because it showed that
especially these DNS packets are 'troublesome'.
The feature 'minimize responses' is included since NSD 3.2.9.
NS RRsets that would go into the Authority section in positive
responses are not considered REQUIRED and therefore will NOT lead
to setting of the TC bit. The minimal response size is:
- 512 in case of no EDNS;
- 1460 in case of EDNS/IPv4;
- 1220 in case of EDNS/IPv6;
- the advertized buffer size if that value is smaller than the
the EDNS defaults.
The feature can be disabled during build time with
--disable-minimal-responses.
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 existence. 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.
"NSEC3PARAM" 51, # RFC 5155.
"TLSA" 52, # RFC 6698.
Unknown 53 - 98,
"SPF" 99, # RFC 4408 (Experimental).
"UINFO" 100, # [IANA-Reserved]
"UID" 101, # [IANA-Reserved]
"GID" 102, # [IANA-Reserved]
"UNSPEC" 103, # [IANA-Reserved]
"NID" 104, # RFC 6742
"L32" 105, # RFC 6742
"L64" 106, # RFC 6742
"LP" 107, # RFC 6742
"EUI48" 108, # RFC 7043
"EUI64" 109, # RFC 7043
"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
"URI" 256, # RFC 7553
"CAA" 257, # RFC 6844
______________________________________________________________________
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 1995 (IXFR) support only for making requests to other servers.
- IXFR is not served.
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.
Secondary zones: - follows SOA timers. (NSD 2 and before did not)
(RFC 1034, 1035).
RFC 4509 (SHA-256 DS) support.
RFC 4635 (HMAC SHA TSIG) support for mandatory algorithms: hmac-md5,
hmac-sha1, hmac-sha256.
RFC 5001 (NSID) support.
RFC 5155 (NSEC3) support.
RFC 5702 (SHA-2) support.
RFC 5936 (AXFR) support.
RFC 6605 (ECDSA) support.
RFC 6698 (DANE) support for TLSA RR type.
RFC 6742 (ILNP) support for NID, L32, L64, LP RR types.
RFC 6844 (CAA) support for CAA RR type.
RFC 7043 (EUI48+64) support for EUI48, EUI64 RR types.
RFC 7553 support for URI RR type.
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.
14 january 2014 (Matthijs Mekking)
- Updated file with CAA RRtype support.
18 june 2013 (Matthijs Mekking).
- Updated file with EUI48 and EUI64 RRtype support.
25 april 2013 (Matthijs Mekking).
- Removed requirements label compression for RP, RT and AFSDB.
19 november 2012 (Matthijs Mekking).
- Updated file with RFC 6698 (DANE) support for TLSA RR type and
RFC 6742 (ILNP) support for NID, L32, L64, LP RR types.
17 april 2012 (Matthijs Mekking).
- Updated file with RFC 5936 (AXFR) and RFC 6605 (ECDSA) support.
17 october 2011 (Matthijs Mekking).
- Updated file with RFC 5702 (SHA-2) and RFC 4509 (SHA-256 DS) support.
17 october 2011 (Matthijs Mekking).
- Added section on minimal responses.
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,v 1.2 2022/09/24 17:38:17 christos Exp $
