$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 for its in QNAME would overflow the legal size for a , 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 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 . 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 $