[dns-operations] operational impact of empty MNAME and RNAME?

[Doug Barton]

Joe Abley wrote:
> Hey,
> 
> For a zone which definitively doesn't support dynamic updates, the  
> MNAME field in the SOA RDATA seems extraneous.
 >
> Similarly, adding an additional stream of spam by putting real data  
> in the RNAME field seems to verge on the pointless.

I agree with other posters that having a real address here has enough 
benefits to outweigh the costs of a little more spam. I would be sort 
of interested to see what the results would be of testing this theory 
though. :)

> Has anybody tried hosting a prominent zone with these fields empty  
> (e.g. specified as "." in a BIND9 zone file)?

I did a lot of research on this when I was at Yahoo!, and came to the 
conclusion that The Right Thing To Do was to put in a name in one of 
the domains that I controlled, and have that name resolve to 
127.0.0.1. I also added a long TTL for that name, since it wasn't 
going to change any time soon.

 > Was there any negative operational impact?

None. Not a single phone call, card, letter, etc. with hundreds of 
millions of windows clients exposed to this solution in all the 
various areas that I deployed it.

However, in the really annoying but non (DNS) operational impact 
category, I had pushback from several ccTLD registries saying that the 
MNAME field MUST contain the same hostname as the first NS record. The 
registries that required this were bad enough, but I could fix that 
fairly easily by making those TLDs a special case in my zone 
generation script. What really used to chap my hide was the registries 
who would not only require this for the zone file of the domain I was 
actually registering (or updating, etc.) but would ALSO recurse into 
the zone where the name server hostnames were located (which was 
always yahoo.com) and require that the MNAME field in THAT zone match 
the first NS record as well.

The good news is that there are very few registries that require this, 
and some have even relaxed their policies in this area. The bad news 
is that the ones that were not flexible had to be appeased, which 
meant manually adjusting things to suit them. If you're not 
registering a sufficient quantity of ccTLD names in these registries 
to trip over this problem, lucky you. I include it here for 
completeness sake.

I should also point out for completeness sake that those who've taken 
up the mantle of Yahoo! DNS do not seem to have continued my practice, 
probably as a result of the registration problems I mention above 
(since they do still register a large number of ccTLD domains).

hth,

Doug

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