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