[dns-wg] RIPE's MNAME recommendation

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