RFC 1034 and RFC 1035 updates : 1996 and 2136

[Annie Renard <Annie.Renard@nic.fr>]

In the three paragraphs mentioned below. It seems there is an
inconsistency between paragraph I (RFC 1034) on the one hand and II,
III on the other hand. Indeed, one can understand that "all of the
servers for the zone", include the one contained in the SOA RR. Thus,
one can understand that RFC 1034 implies "The primary master MUST
appear in the list of NS for the domain name in question".

If there is no inconsistency, could anybody enlighten us with a
consistent view?

Thanks in advance,

---
        Annie Renard    [nic@nic.fr]
        AFNIC - Immeuble International
	2 rue Stephenson - Montigny-le-Bretonneux 
        78181, Saint-Quentin-en-Yvelines CEDEX, France 
	http://www.nic.fr/
	Personal Email: Annie.Renard@nic.fr

I)
========================================================================
RFC 1034 "DOMAIN NAMES - CONCEPTS AND FACILITIES" (section 4.2.1) :


4.2.1. Technical considerations

The data that describes a zone has four major parts:

   - Authoritative data for all nodes within the zone.

   - Data that defines the top node of the zone (can be thought of
     as part of the authoritative data).

   - Data that describes delegated subzones, i.e., cuts around the
     bottom of the zone.

   - Data that allows access to name servers for subzones
     (sometimes called "glue" data).

[...]

!!!! Though logically part of the authoritative data, the RRs that describe
the top node of the zone are especially important to the zone's
management.  These RRs are of two types: name server RRs that list, one
per RR, all of the servers for the zone, and a single SOA RR that
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
describes zone management parameters.
========================================================================

II)
========================================================================
RFC 1996 "A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY)" (section 2.1) (Standards Track, updates 1035)

2. Definitions and Invariants

   2.1. The following definitions are used in this document:

   Slave           an authoritative server which uses zone transfer to
                   retrieve the zone.  All slave servers are named in
                   the NS RRs for the zone.

   Master          any authoritative server configured to be the source
                   of zone transfer for one or more slave servers.

!!!!   Primary Master  master server at the root of the zone transfer
                   dependency graph.  The primary master is named in the
                   zone's SOA MNAME field and optionally by an NS RR.
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                   There is by definition only one primary master server
                   per zone.
========================================================================

III)
========================================================================
RFC 2136 "Dynamic Updates in the Domain Name System (DNS UPDATE)" ,
(section 4.3) (Standards Track, updates 1035)


4.3. If the requestor has reasonable cause to believe that all of a
   zone's servers will be equally reachable, then it should arrange to
   try the primary master server (as given by the SOA MNAME field if
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   matched by some NS NSDNAME) first to avoid unnecessary forwarding
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   inside the slave servers.  (Note that the primary master will in some
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   cases not be reachable by all requestors, due to firewalls or network
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   partitioning.)
   ^^^^^^^^^^^^^^
========================================================================