[dns-wg] RIPE's MNAME recommendation

On Fri, 30 Sep 2005, Paul Herman wrote:

> Hello dns-wg list!
>
> SUMMARY:
> In short, in a SOA RR of ours we have an MNAME that corresponds to a
> primary master server which has a private IP address.  This is causing
> problems with many RIPE member registrars.
>
> PROBLEM:
> Using the language described in Section 2.1 of [RFC 1996], we have a
> primary master DNS server and two slave DNS servers.  The primary
> master has a private [RFC 1918] IP address and the Slaves have public
> IP address, are named in the NS RRs for the zone and use zone transfer
> to recieve the zone from the primary master.  Furthermore, in
> accordance with [RFC 1996], [RPC 1035] and [RIPE1] I have named the
> primary master as the original/primary source of the data for the
> zone.  Here is an example zone file from what I'm talking about:
>
>      example.com.  3600  SOA  dns.private.example.com. hostmaster.example.com. (
>                           1999022301   ; serial YYYYMMDDnn
>                           86400        ; refresh (  24 hours)
>                           7200         ; retry   (   2 hours)
>                           3600000      ; expire  (1000 hours)
>                           172800 )     ; minimum (   2 days)
>                  NS slave1.example.com.
>                  NS slave2.example.com.
>      slave1      A  {public-ip}
>      slave2      A  {public-ip}
>      dns.private A  10.11.12.13
>
> So far so good.  Our zone appears to be fully RFC compliant.  However,
> the problem arises when I try to transfer, say, the ownership of
> a ".de" zone using DENIC, because [RIPE1] additionally recommends
> that this be a valid address of the primary master, "valid" being the
> key word here.  This is a problem, because many RIPE member registrars
> are indeed enforcing this policy.
>
> I gather, however, from more recent messages from Mr. Koch (who authored
> [RIPE1]), that the "MNAME field need not be part of the NS RRSet and
> need not be accessible." [ICANN-FORUM].  BTW, to my knowledge this
> is also neither enforced by IANA nor ICANN.
>
> Is it possible that RIPE could consider relaxing this "recommendation"
> that causes problems for RFC compliant zones?  How do you, the DNS
> community, feel about this?
>
> Thank you for your attention in this matter.

What the recommendation [ripe-203] says, is:

(1) The DNS specification explicitly states that the primary master server
be named here.

(2) The value must be determined and used.

ad (2) I have no idea what this means.

(3) Especially it is a mistake to repeat the zone name here, unless this
also leads to a valid address of the primary master.

ad (3) The terms 'valid' and 'leads' are subject to broad interpretation.
Does 'valid' mean 'reachable', does 'leads' mean 'globally resolvable' ?
I think this is trying to reflect rfc2181, section 7.3. But, also this
section does not reveal why this is a mistake.

IIRC, the MNAME field is used in two parts of the DNS protocol, notify and
dynamic update.

For notify, the primary master determines the recipients of a notify
message by determining the nameservers of the zone (the NS set in the
apex) minus the name of the primary master (determined by the mname
field). It does not have any impact to have a private space address for a
host specified in the MNAME field, since it would not receive a notify
message.

For dynamic update, the requestor determines the recipient of a dynamic
update message by sending it first to address of the host in the MNAME
field to avoid unnecessary forwarding in slave servers, and, if that
fails, try the other servers. So, if this is a zone that contains
addresses of hosts, where the hosts are trying to dynamically update their
addresses (or other data), you might see updates directed to the host in
the MNAME field. If this, from the dyn.update host view, is not a
reachable address, it will try the slave servers.

I do not know if there are any other uses of the SOA MNAME field, or what
future uses might be. I do not know how 'stuff breaks' by having a private
space address for the host listed in the SOA MNAME field.

I would, in general, try to avoid leakage of private space addresses in
any way, shape or form, since I don't know what other uses of the MNAME
are.

But, using this recommendation as a policy and bluntly forcing it onto
others, without a good explanation of why, is not a good thing.

Roy