Re: RFC 1034 and RFC 1035 updates : 1996 and 2136

[Kevin Darcy <kcd@daimlerchrysler.com>]

"All of the servers for the zone" means all of the nameservers which are
available to authoritatively answer queries for the zone. If the master is not
available to answer queries for the zone, i.e. when it is a so-called "hidden
master", then it doesn't need to be listed in the NS RRset. "Stealth" slaves,
i.e. slaves which are not listed in the NS RRset, are also perfectly legal.



- Kevin

Annie Renard wrote:

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