RFC: workaround for unwanted dynamic updates

[Doug Barton]

Greetings,

	Among other things, I administer name servers which house a lot
(six figures) of zones for our customers. For a long time now, we've had a
problem with customers setting up their win 2k boxes (et al) with
hostnames in the domains they purchase from us, which (as I understand it)
has the "register your host in dns" option turned on by default. In any
case, after reading several discussions about the same problem on this
list, all without a solution that would work for us, I hit upon the idea
of changing the MNAME field in the SOA to be bogus-name.mydomain.com,
which would prevent the errant w2k machine from being able to contact any
of my servers with their update packets.

	Prior to my implementing this fix it was not uncommon to get hit
with 20 failed dynamic update requests per second. The overhead of
processing those requests was just shredding the server. At its best that
server was doing 40 queries per second, currently (without the dynamic
updates overhead) it's doing 3 times that many qps.

	My purpose in writing is twofold. First, to offer this as a
potential solution for others that are in my position; with apologies to
anyone who might have already suggested this in a thread that I missed.
Second, is to throw the topic open for discussion to see if there might be
a downside that I missed in my testing. Before deploying this I did test
with a win 2k machine to try and make sure I wasn't breaking anything. The
potential downside seems small given that the updates already were not
succeeding. I'm aware that the MNAME field is not generally used by
anything other than dynamic updates, although some ccTLD registries
(especially .fr) do check to see if this field matches the primary name
server... although I still don't understand why. :) To avoid that issue,
I'm not changing my .fr zone file template, although I've changed the
others. I've been using the bogus MNAME for a week now, so far no
customer, or any other kind of complaints related to this issue.

	Potential questions in my mind right now are, would it be better
to make the bogus MNAME something that actually resolves? My reason for
not doing that initially is based on reasoning that if the name resolves,
the win 2k machine is going to try to send that IP packets, and may get
confused by the lack of response. Since the name doesn't resolve, no
packets are going anywhere, which is probably the right thing. I have the
neg. ttl field set fairly high on the domain that the bogus name is in
since that's my "administrative" domain, and it's very rare for anything
to change there.

	Another idea is to actually set up a name server on an IP whose
only job is to reject the dynamic updates. The problem I see with that is
that we're still wasting (a small amount of) bandwidth, and those win 2k
machines are very insistent. The first burst of updates comes when the
machine boots... 5 in a row spaced one second apart. Then it sends other
bursts periodically while the machine is up. The other side of this coin
would be to set up a name server (or simillar construct) whose only job is
to say yes to the dynamic updates. That would make the win 2k server
happy, and eliminate the regular retries. However, I'm not sure what that
would break down the road (I'm far from a windows expert) and it just
feels wrong to me. Given that my first choice solution worked with no
apparent ill effect to the win 2k machine I tested on, I thought it was
safest.

	So, what do y'all think? Opinions are welcome, especially from
those knowledgeable about windows. Of course, my FIRST choice was to make
my MNAME dns1.cp.msft.net, but I didn't think that'd fly with the
lawyers....

TIA,

Doug