xref: /src/external/bsd/nsd/dist/doc/REQUIREMENTS

Id


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