$Id: REQUIREMENTS 1703 2005-10-31 15:16:15Z miekg $


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,


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 NOTIMPL  (rfc1035)
       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
 
     + Other sections should be empty otherwise 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

      [OK***: 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.
      ]

    + 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 not 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). 

  [OK*** this version of the REQUIREMENTS includes DNSSEC specs
   assuming DS and OPT-IN style NSEC records.]

   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
         SIG(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 SIGs 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 SIG(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 SIG(NSEC) in the authority section.
	   
	      else 

	        we are in an opt-in part of the zone and we should
	        include the the NSEC RR of the last secured RR in the
	        zone and the corresponding SIG(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 SIGs 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
	          [DNAME processing is deferred.
	 
	          If a DNAME record exists at that point, copy that record into
		  the answer section, if the DO bit is set also copy the SIG.

		  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.
		  
		  ] 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 SIG for the *
         label and matching QTYPE also set the owner of the SIG 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 KEY of the
      same name should be added. For retrieval of type A, AAAA or A6 RRs 
      the KEY should also be included.
      See section 4.2 as well.



  Note that on a QNAME match the NS records are not copied into the AUTH
  section (This is a requirement from step 4 'matching down the cache'
  from rfc1034 4.3.2).  This is a requirement only for caching
  servers. BIND8 will copy the the NS in the Auth section for
  authoritative server too.




C 4.2 Additional Data processing.


  Additional data is added as long as there is space in the packet.

  When processing the additional section priority is (rfc 2535 3.5 and
  rfc 2874 4) 
      + A 
      + A6 
      + AAAA 
      + KEY

  For truncation see section C.4.4

  If the DO bit is set SIGs 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 
      + SIG A
      + A6 
      + SIG A6
      + AAAA 
      + SIG AAAA
      + KEY
      + SIG KEY

  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.

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.).

   -AFSDB, RP, RT   (rfc1183, Section 1,2 & 3.3.3)

    The format of these RR does is not CLASS specific so compression
    is done for:
    dname of the 'hostname' field for AFSDB
    dname of the 'mbox-dname' and 'txt-dname' for RP
    dname of the 'intermediate-host' for RT.
        

   [** This is incorrect.  I don't think compression is allowed and NSD2
    doesn't perform compression. -Erik]    
    SIG signers name field MAY be compressed.  (2535 4.1.7)
    NSEC dname field MAY be compressed.  (2535 4.2)




  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 SIG
  RRs are required in the answer and authority section.


  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.

  If QNAME does not match a name from the zone then the negative
  response is to be constructed so that all possible wildcard matches
  are denied existence.   

  [OK**** This is not yet complete. We need to work out the algorithm for
  NSEC processing]



-------------------------------------------------------------------------------

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,    # Not ASSIGNED YET...!!! draft
  "UINFO"    100,   # [IANA-Reserved]
  "UID"      101,   # [IANA-Reserved]
  "GID"      102,   # [IANA-Reserved]
  "UNSPEC"   103,   # [IANA-Reserved]
  "TKEY"     249,   # RFC 2930
  "TSIG"     250,   # RFC 2845
  "IXFR"     251,   # RFC 1995
  "AXFR"     252,   # RFC 1035
  "MAILB"    253,   # RFC 1035 (MB, MG, MR)
  "MAILA"    254,   # RFC 1035 (obsolete - see MX)
  "ANY"     255,    # RFC 1035



______________________________________________________________________

Appendix B  Details on specific design and implementation choices.


B.1. Returning the root delegation when no answer can be found

   From RFC1034/1035 it is not obvious if returning a root delegation
   is a (non-)requirement for authoritative servers.

   We have decided not to implement a root-hints since an
   authoritative server should in normal circumstances only receive
   queries for which the server is authoritative.
   
   Also see RFC 1123 section 6.1.2.5.

   Whenever an answer cannot been provided we return a SERVFAIL. It
   has been argued that this is a policy decision and thus a REFUSE
   should be returned. However, in the spirit of RFC1034/1035 a server
   should return cached data, if that cache cannot be reached a SERVFAIL
   is an appropriate response.

   Also see the discussion on the 'namedroppers list' Starting April
   2002 with subject "name server without root cache "
   (ftp://ops.ietf.org/pub/lists/)





______________________________________________________________________

Appendix C (Planned) Features


RFC Standards

  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)

    
   Planned implementation


   - 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)

   - RFC 1996 (Notifies) will be available in 1.1.0 or later.



   - 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.

   - RFC 3123 (APL RR) will be implemented in 1.0.1 or later and not
		      later than 1.1.0
      
   Deferred implementation

   The following proposed standards will not be implemented in NSD
   1.0.0, Release of these features will probably not happen before NSD
   1.1.1.

   - RFC 2672 (DNAME)
   - RFC 2673 (Binary labels)
   - RFC 2874 (A6)

  Not implemented:

  Proposed standards RFC1995 (IXFR), RFC2136
  (Dynamic update) are not implemented and will not be implemented as
  zone control is not implemented in NSD itself.

______________________________________________________________________
$Id: REQUIREMENTS 1703 2005-10-31 15:16:15Z miekg $


