Re: [dns-wg] RIPE's MNAME recommendation

[Doug Barton <]

Peter Koch wrote:

> So, my suggestion is to adjust the MNAME text in a way that keeps the
> original spirit but explicitly says that the name in MNAME 
> 
> 1) must resolve to an A RR(Set) 
> 2) the address (or, to complicate matters, addresses) must be the public
>    address of the (hidden/stealth) primary master

I am curious as to what the purpose of this text would be. If that field is
used for either notify or dynamic update (as Roy pointed out earlier in the
thread) those are both issues that are relevant only to the operators of the
name servers and/or the domain administrators in question. The AXFR issue
that Daniel mentioned is also a matter of local policy. In short, without
significant good reasons to the contrary (with supporting information and
references included in the document), I think if 203 says anything about it
at all, it should say only that what goes into that field is a matter of
local policy.

If the thinking on this topic is being guided by (now stale) RFC statements
on this topic, it would probably be useful to consider a document in the
IETF process to update this.

I would also like to point out that there is an alternative that I haven't
seen mentioned to having the MNAME be either a publicly routable or private
address. Back when I was managing DNS for a living, I used to create a
hostname called hidden-master.example.com, and have that host resolve to
127.0.0.1. That neatly solved many problems, including the overwhelming
flood of traffic we were seeing on the (valid) server name that used to be
listed in the MNAME field from Windows clients trying to do spurious dynamic
updates. I tested this before we deployed it, and it doesn't harm the
Windows clients, and it solved our problem. The only time that we had
trouble with this was when we would attempt to register country-code domains
at certain registries with this configuration.

As long as we're talking about updating 203, I'd also like to take this
opportunity to point out that the current discussion highlights some of the
problems with documents of this type, namely that they are generally out of
date within minutes of being published. For example, the recommendation for
the MINIMUM field is woefully out of date (as I'm sure is not a surprise to
most members of this list). I would also argue that the recommendations for
refresh, retry, and expire are only applicable to a fairly narrow part of
the bell shaped curve of DNS administration, and should not be adopted
blindly without good understanding of both the needs of the domain
administrators and how those values interact. I think that a lot of this
information was useful at the time it was published, but 6 years is loooong
time in net.years.

hope this helps,

Doug


-- 

	If you're never wrong, you're not trying hard enough