NOTIFY-triggered Auto-slaving (was Re: how to list ALL zones of my master server)

[Kevin Darcy]

Jim Reid wrote:

> >>>>> "Kevin" == Kevin Darcy <kcd at daimlerchrysler.com> writes:
>
>     Kevin> Jim, I haven't seen anyone suggest that all of this
>     Kevin> implementation-specific configuration data be crammed into
>     Kevin> the NOTIFY packet.
>
> Indeed. However this is the logical next step if NOTIFY was to be
> abused like the OP suggested. Why just add the zone and not have some
> way of adding the zone-specific configuration info? Ever heard of the
> phrase "function creep"?

So are you objecting to the suggestion as it has been stated, or are you
objecting to what you perceive might be the "logical next step" of the
suggestion? I consider this a straw man argument. The suggestion stands
or falls on its *own* merits, not the merits of some chimeric "logical
next step"...

>     Kevin> I really don't understand why people are so hostile to
>     Kevin> using NOTIFY as a zone-creation trigger.
>
> Well for starters the NOTIFY protocol was not intended to do such a
> thing.

True, but so what? This mechanism would in no way impede the intended
function of NOTIFY.

> If someone wants a DNS provisioning protocol to add/remove
> zones or change zone-specific configuration options, why not define
> and implement something that was properly developed for that specific
> purpose? Why corrupt another protocol that was never intended to
> provide that functionality?

It's not a "corruption". I repeat: this mechanism would in no way impeded
the intended function of NOTIFY.

As for this hypothetical "DNS provisioning protocol", I agree it would be
a useful thing to have. But there is no proposal, no working group, no
development in this area. Wanna start the ball rolling? I'm in.

In the absence of any such initiative in the foreseeable future, however,
why not make reasonable use of the protocol extensions which are already
available? Sometimes you have to settle for a Neon when a Mercedes isn't
within your means (although of course I heavily recommend everyone buy a
Mercedes if they can possibly do so :-)

>     >> And as for the DoS possibilities...
>
>     Kevin> I see this as just another facet of the trust issue, which
>     Kevin> you said you were ignoring.
>
> That's why I didn't enumerate them: my remark simply indicated that
> there are serious DoS problems with the OP's suggestion. I was also
> thinking about a trust problem on the slave server where the name
> server process has the ability to read but not change its config file.

As an implementation matter, I wouldn't recommend giving the nameserver
process free rein over the whole config file. The list of
"auto-slaved" zones should be stored separately (think a souped-version
of "include"). In this way, even if a hacker were to get as far as being
able to manipulate files owned by the nameserver process, being able to
manipulate the the "auto-slave" list really wouldn't buy him/her any more
privileges than being able to manipulate the contents of the zone files
directly.

For an extra helping of paranoia, perhaps the newly-created zones could
be put on "probation" for a while until a human actually "promotes" the
zone to a full-fledged slave zone. If not promoted within a certain
(configurable) time period, the zone would "expire", and never be
auto-created again absent human intervention. Even if the time period
were set as low as 24 hours, for a busy hosting outfit a once-a-day
"promotion session" would still be a win over having to log into the
slave(s) multiple times a day to edit named.conf (especially if the
promotion operation could be done remotely-yet-securely, e.g. through
rndc).

>     Kevin> If the NOTIFY is unsigned or the signature doesn't verify,
>     Kevin> ignore the NOTIFY. How is this a serious DoS possibility?
>
> Flooding the server with duplicated NOTIFYs? Who cares if the
> signatures or timestamps don't verify? Just keep the server busy
> verifying them: great fun on a single-threaded server.

And how is this different from DoS'ing a server by attempting an
unauthorized SSH connection, an unauthorized SMTP connection, or
whathaveyou? The simple fact is that if you make a server generally
available on the Internet, even if you use robust authentication and/or
authorization methodologies, you are still vulnerable to some level of
DoS. This is a threat that can be minimized by intelligent implementation
but cannot be eliminated entirely. Hopefully the NOTIFY authentication
code would be optimized to efficiently weed out the obviously-bogus
attempts before committing too much to resource-intensive tasks like
crypto signature-verification.


-Kevin