workaround for unwanted dynamic updates

[F. Even]

Would setting MNAME to something that does not resolve at all break things
(not exactly clear if this is what Doug has done or not).  What would happen
on the client side if it were set to nothing?

Apologies if this has been covered somewhere before,
Frank

----- Original Message -----
From: "Cricket Liu" <cricket at menandmice.com>
To: "Doug Barton" <DougB at DougBarton.net>; <bind-users at isc.org>
Sent: Thursday, December 13, 2001 5:19 PM
Subject: RE: workaround for unwanted dynamic updates



> 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.

That's a good idea.  I think it's been invented in parallel by several
people, including my friend Mike Milligan.

> 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.

The only other DNS mechanism that I know of that uses the MNAME field
is NOTIFY.  NOTIFY messages aren't sent to the name server listed in
the MNAME field.  But if the primary master receives a NOTIFY message,
it'll just ignore it.

> 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....

I like the idea of setting up a name server to allow all the dynamic
updates.  How about setting up a "dynamic update honey pot":

options {
allow-query { none; };
};

zone "." {
type master;
file "db.root";
allow-update { any; };
};

I'm not sure that would work, but it'd be funny.

cricket

Men & Mice
DNS Software & Services
www.menandmice.com

Attend our next DNS and BIND class!  See
http://www.menandmice.com/8000/8000_dns_training.html
for the schedule and to register for upcoming classes