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

[Peter Koch <]

On Sat, Oct 01, 2005 at 01:49:30PM +0200, MÃ¥ns Nilsson wrote:

> In the interest of sanity, I'd suggest adding "should answer queries about
> said domain with the AA bit set" (in addition to swallowing/properly
> rejecting/processing updates and allowing/properly refusing zone
> transfers). That is the The Right Thing to do, IMHO, but it might be hard

There's no RFC that would support this as far as I can see. At least there's
no RFC that suggests that the server named in MNAME act as an additional
resource to what is already in the NS RRSet.

When RIPE-203 was written, NOTIFY was pretty much in use and that's what the
recommendation is mostly based on. At that time some DNS server or admin
tool defaulted to the zone name for MNAME and since even NOTIFY doesn't fail
if you do not enter the primary master (or the root of the XFR dependency graph,
as RFC 1996 puts it), people just accepted that "default" not knowing that
it really needed editing. NOTIFY's MNAME use affects the secondaries and the
primary master in that it limits the amount of notifications sent and tries
to avoid any NOTIFYs going back to the primary master. It may also affect
query load when servers do SOA additional section processing (contrary to
the words in RFC 1035).

At the same time, Dynamic Updates were in far less use, at least far less than
today thanks to a prominent OS. Dynamic Update traffic affects more parties
and sometimes is so dominant, that the MNAME is used as a dedicated "DunUpd
target", e.g. by AS112. Strictly speaking, RFC 2136 only suggests to target
MNAME if the name appears in the NS RRSet, but current reality is different.

None of the above says or suggests that the server in MNAME be used for
DNS queries from random sources or that it should serve the zone via XFR.

Then, RIPE-203 explicitly targets "small and stable zones", which are more
or less by definition not subject to dynamic updates (if, for a moment,
we associate "dynamic updates" with "frequent updates"/DHCP; if DynUpd is
used as a provisioning tool by the zone maintainer, it likely can get away
even without the SOA info).

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

Please remember that RIPE-203 does not try to be an exhaustive (even less so
normative) explanation for all the SOA RR's parameters for most any situation.
It aims at a rather large subset (maybe in the 70-80%) of zones which can
live well with these defaults.

-Peter