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

[David Botham]

> -----Original Message-----
> From: bind-users-bounce at isc.org [mailto:bind-users-bounce at isc.org] On
> Behalf Of Kevin Darcy
> Sent: Monday, September 30, 2002 7:28 PM
> To: comp-protocols-dns-bind at isc.org
> Subject: NOTIFY-triggered Auto-slaving (was Re: how to list ALL zones
of
> my master server)
> 
> 
> 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.

Me Too!

Dave...

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