On Fri, Sep 30, 2005 at 01:19:41PM +0200, Paul Herman wrote:
example.com. 3600 SOA dns.private.example.com.
[...]
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,
RFC 1918 says that you should not leak "private" IP addresses, including reference to those addresses in DNS RRs (last paragraph in section 3). The A RR at dns.private.example.com and the reference to that name in the SOA RR do not follow this guidance.
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'm not sure I understand the problem here. What do those registrars "enforce" exactly? RIPE 203 addresses the MNAME field because it was (and maybe continues to be) a common mistake to just repeat the zone name in the MNAME field, where that name does not own any A (or maybe AAAA) RR. In retrospect I'd admit that "valid" is an ambiguous term. However, leaking private address space in DNS RRs, especially in situations where it might cause traffic to go to random targets is not a good idea even today IMHO. What error(?) message do those registrars send back? Note, also, that RIPE 203 is not a normative document but a recommendation for a specific type of zone that happens to appear rather often. Without seeing the policy that "enforces" RIPE 203 it is a bit hard to say whether or not that's a good idea.
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
There is no inconsistency between my comment in that forum and RIPE 203. Many DNS setups use stealth primaries and even if those accept and respond to NOTIFY and Dynamic Update messages, there's no rule that the system named in the MNAME field respond to DNS queries (unless it is also announced per an NS RR). The IANA procedures draft which this comment addressed could be read in a way that thet system in the MNAME field would also be checked for SOA values and consistency.
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?
First of all, RIPE 203 is up for review at the upcoming RIPE meeting, although for a different reason (the "minTTL" field values recommendations are most likely outdated due to the widespread deployment of negative caching). Then there seems to be a mixture of policies and references to normative and non-normative documents. If I understand you correctly some registrar refuses to deal with a zone where the MNAME field refers to a name that owns an A RR carrying an RFC 1918 address. Seems not too unreasonable to me. -Peter