NOTIFY-triggered Auto-slaving (was Re: how to list ALL zones of my master server)
dns at botham.net
Tue Oct 1 15:56:17 UTC 2002
> -----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
> 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
> > 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
> > way of adding the zone-specific configuration info? Ever heard of
> > phrase "function creep"?
> So are you objecting to the suggestion as it has been stated, or are
> objecting to what you perceive might be the "logical next step" of the
> suggestion? I consider this a straw man argument. The suggestion
> 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
> > 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
> the intended function of NOTIFY.
> As for this hypothetical "DNS provisioning protocol", I agree it would
> 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,
> why not make reasonable use of the protocol extensions which are
> available? Sometimes you have to settle for a Neon when a Mercedes
> within your means (although of course I heavily recommend everyone buy
> 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,
> > 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
> As an implementation matter, I wouldn't recommend giving the
> process free rein over the whole config file. The list of
> "auto-slaved" zones should be stored separately (think a
> of "include"). In this way, even if a hacker were to get as far as
> able to manipulate files owned by the nameserver process, being able
> manipulate the the "auto-slave" list really wouldn't buy him/her any
> privileges than being able to manipulate the contents of the zone
> For an extra helping of paranoia, perhaps the newly-created zones
> be put on "probation" for a while until a human actually "promotes"
> 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
> > Kevin> If the NOTIFY is unsigned or the signature doesn't
> > 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
> authorization methodologies, you are still vulnerable to some level of
> DoS. This is a threat that can be minimized by intelligent
> 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.
More information about the bind-users