wiki:RfcCompliance

Introduction

DNS is defined by a large number of standards described in the RFC series of documents. This page describes the compliance of BIND 10 to those RFCs, listing the features defined by each document and indicating whether or not BIND 10 implements the feature.

Each of the sections below concerns one RFC. For each RFC is listed:

  • The features of the RFC
  • Whether BIND 10 implements the feature.
  • Any qualifications or notes.

RFC 1995

Incremental transfer of zone information (IXFR) is described in this standard. Rather than transfer the entire zone between a master and slave when the zone is updated, RFC 1995 describes a protocol whereby only differences between the information in the master and slave is transferred.

There are two aspects to IXFR, the ability to receive an IXFR (IXFR-in) and the ability to send an IXFR (IXFR-out). As some of the features in the standard apply to both, the aspects are considered separately below.

The BIND 10 system test specification for IXFR can be found here.

Feature Implemented Notes
IXFR-in
Generation of IXFR request on receipt of NOTIFY No
Generation of IXFR request on SOA refresh timeout No
IXFR over UDP No Few nameservers have implemented this feature.
IXFR over TCP Yes
Fallback to AXFR if IXFR query is not recognised No
IXFR-out
IXFR over UDP No Few nameservers have implemented this feature.
IXFR over TCP No
Forcing IXFR over TCP if data does not fit into a single UDP packet No
Forcing AXFR if IXFR data is larger than entire zone No
Returning entire zone if IXFR is disabled No Currently BIND 10 must receive an AXFR request to transfer the entire zone
Condensing multiple difference sequences into single difference sequence No This is an optional part of the standard
Other
Use UDP checksum If enabled On modern systems, this feature is enabled on a system-wide basis. BIND 10 does not explicitly enable UDP checksums.
Retry over TCP if checksum is zero No BIND 10 does not access the UDP checksum.

Detailed Requirements for RFC 1995

RFC 5155

The use of the NSEC3 resource record to provide authenticated denial of existence is described in this RFC. The alternative NSEC RR denies the existence of a name by providing information on two owner names and asserting that the zone contains no name between them. The NSEC3 RR essentially does the same, but to avoid providing the capability to enumerate the zone, uses hashes of names. It also include an "opt-out" feature to reduce the number of signatures in zones that have a lot of unsigned delegations.

Feature Implemented Notes
Authoritative Server
Support of both mandated algorithms
Rejection of zones with invalid NSEC3 data
Support of NSEC3 RRs
Support of NSEC3PARAM RR
Support of Opt-Out
Delivery of NSEC3 authenticated denial of existence when queried with DO bit set
Resolver
Rejection of invalid NSEC3 RRs
Able to interpret NSEC3 RRs in the response

Detailed Requirements for RFC 5155

RFC 2136

Dynamic Updates in the Domain Name System (DNS UPDATE, or DDNS) is described in this standard.

The BIND 10 system test specification for DDNS can be found [DDNSSystemTests here].

Feature Implemented Notes
Authoritative Server
DDNS over UDP No
DDNS over TCP No
DDNS Zone Section processing Yes
DDNS Prerequisite Section processing Yes
DDNS Update Section processing Yes
DDNS Additional Section processing No Unclear whether there is anything here we will implement
DDNS and support for IXFR-out Yes
Last modified 5 years ago Last modified on May 30, 2012, 7:32:54 PM