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