NOTIFY-triggered Auto-slaving (was Re: how to list ALL zones of my master server)
Kevin Darcy
Jim Reid wrote:
> >>>>> "Kevin" == Kevin Darcy <k...@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
Jim Reid
>> 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"?
Kevin> So are you objecting to the suggestion as it has been
Kevin> stated, or are you objecting to what you perceive might be
Kevin> the "logical next step" of the suggestion?
Both. I'm objecting to a protocol being corrupted and abused for
things it was never designed to do.
>> Well for starters the NOTIFY protocol was not intended to do
>> such a thing.
Kevin> True, but so what? This mechanism would in no way impede
Kevin> the intended function of NOTIFY.
Oh yeah? How do you figure that out? If NOTIFY is to be abused for
automatic zone slaving, presumably some header bit -- which one? -- or
extra RR in the packet would be needed to tell the server to slave
some zone instead of treating the packet as a regular NOTIFY. That
means a protocol change. Which is an impediment to the intended
purpose of NOTIFY. Or if the protocol remains unchanged, it implies
some extra config file goop to tell the server which NOTIFYs mean
"NOTIFY" and which mean "add this zone". [Hey, what about "remove this
zone?"] That would require as much admin effort as just adding the
zone{} statements in the first place.
>> 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?
Kevin> It's not a "corruption". I repeat: this mechanism would in
Kevin> no way impeded the intended function of NOTIFY.
Yes it does. How would a name server be expected to distinguish
between a regular NOTIFY as defined in RFC1996 and one which means
"slave this zone if you don't already slave it"? And what happens if
the intended slave server can't or won't slave the new zone it's been
told to serve? How does the victim server get that message back to the
source of the NOTIFY? Or is that something to just not bother about?
Kevin> As for this hypothetical "DNS provisioning protocol", I
Kevin> agree it would be a useful thing to have. But there is no
Kevin> proposal, no working group, no development in this area.
So go ahead and start one. This would be a more productive thing to
spend time on than advocating to cruft unsightly warts on to the
NOTIFY protocol.
Kevin> For an extra helping of paranoia, perhaps the newly-created
Kevin> zones could be put on "probation" for a while until a human
Kevin> actually "promotes" the zone to a full-fledged slave
Kevin> zone. If not promoted within a certain (configurable) time
Kevin> period, the zone would "expire", and never be auto-created
Kevin> again absent human intervention. Even if the time period
Kevin> were set as low as 24 hours, for a busy hosting outfit a
Kevin> once-a-day "promotion session" would still be a win over
Kevin> having to log into the slave(s) multiple times a day to
Kevin> edit named.conf (especially if the promotion operation
Kevin> could be done remotely-yet-securely, e.g. through rndc).
This is too silly for words. The human who does this "promotion" could
just as easily add new zone{} statements to named.conf, obviating the
need for this bizarre proposal.
Another point: as I'm sure you realise, there's a lot more to serving
DNS zones than updating config files. Anyone who does this job
responsibly will already be doing a lot of provisioning for that zone:
capturing contact details for the zone's admin and technical contacts,
keeping track of contract expiry and renewal dates, making sure the
domain name has been approved by the competent authority (eg corporate
naming standards), determining which name servers to use, logging and
auditing change requests, documenting the name servers that are used,
etc, etc. So the task of adding the zone{} statement is just a one
small part of the overall process. And one that can be automated too.
There will probably be (or should be) a simple workflow item that's
part of routine operations to add and remove zones from name servers.
Given this exists, why bother contorting NOTIFY to do something it was
never intended to do?
Mark Damrose
news:anbncl$5to2$1...@isrv4.isc.org...
>
> Kevin> True, but so what? This mechanism would in no way impede
> Kevin> the intended function of NOTIFY.
>
> Oh yeah? How do you figure that out?
The intended function of NOTIFY
<QUOTE RFC1996>
Abstract
This memo describes the NOTIFY opcode for DNS, by which a master
server advises a set of slave servers that the master's data has been
changed and that a query should be initiated to discover the new
data.
</QUOTE>
A new zone is a change, just as much as the contents of an existing zone.
If NOTIFY is to be abused for
> automatic zone slaving, presumably some header bit -- which one? -- or
> extra RR in the packet would be needed to tell the server to slave
> some zone instead of treating the packet as a regular NOTIFY. That
> means a protocol change. Which is an impediment to the intended
> purpose of NOTIFY. Or if the protocol remains unchanged, it implies
> some extra config file goop to tell the server which NOTIFYs mean
> "NOTIFY" and which mean "add this zone". [Hey, what about "remove this
> zone?"] That would require as much admin effort as just adding the
> zone{} statements in the first place.
Yes, it would require extra "goop" in the config file. All feature changes
do. If the NOTIFY is one for a zone that is already configured - it is a
standard one. If it is one for a zone that is not already configured - and
the master matches the list allowed to autoconfigure, then it means "add
this zone".
I would modify the proposal to trigger an iterative SOA query - to verify
that the master is authoritive for the zone before adding it.
For removal, if it is an autoconfigured zone and it expires - delete it.
Expired zones are suppressed anyway. If an expired/deleted zone is fixed on
the master (or the transport problem is fixed) autoconfigure it again.
>
> Kevin> It's not a "corruption". I repeat: this mechanism would in
> Kevin> no way impeded the intended function of NOTIFY.
>
> Yes it does. How would a name server be expected to distinguish
> between a regular NOTIFY as defined in RFC1996 and one which means
> "slave this zone if you don't already slave it"? And what happens if
> the intended slave server can't or won't slave the new zone it's been
> told to serve?
The same thing that happens with a slave that isn't manually configured
(lame server / no zone transfers in log) or with a slave that can't serve
the domain and is manually configured (errors on slave).
How does the victim server get that message back to the
> source of the NOTIFY? Or is that something to just not bother about?
No response or NOTIMP response triggers an autoconfigure aware master to log
an error.
>
> Kevin> As for this hypothetical "DNS provisioning protocol", I
> Kevin> agree it would be a useful thing to have. But there is no
> Kevin> proposal, no working group, no development in this area.
>
> So go ahead and start one. This would be a more productive thing to
> spend time on than advocating to cruft unsightly warts on to the
> NOTIFY protocol.
The benefit of using NOTIFY is that it already exists. If you have multiple
kinds of servers or can't upgrade all at once, it could be made backwards
compatable with existing servers that support NOTIFY.
>
> Another point: as I'm sure you realise, there's a lot more to serving
> DNS zones than updating config files. Anyone who does this job
> responsibly will already be doing a lot of provisioning for that zone:
> capturing contact details for the zone's admin and technical contacts,
> keeping track of contract expiry and renewal dates, making sure the
> domain name has been approved by the competent authority (eg corporate
> naming standards),
All of which is done offline before adding the zone to the master.
> determining which name servers to use,
This feature would be most usefull if that had been pre-configured and a
policy set to: All zones created on server1 are slaved on server2, all
zones on server3 slaved on server4, etc.
logging and
> auditing change requests,
Again done before you add/remove zone on master.
documenting the name servers that are used,
> etc, etc. So the task of adding the zone{} statement is just a one
> small part of the overall process. And one that can be automated too.
> There will probably be (or should be) a simple workflow item that's
> part of routine operations to add and remove zones from name servers.
> Given this exists, why bother contorting NOTIFY to do something it was
> never intended to do?
For someone setting up a new service, this is something they need to create.
What's wrong with having a standard supported way to do it. Automating zone
additions on a slave is only valuable if you re-invent it yourself? How
about the scenario where you have an inter-department or inter-comany
agreement "I'll slave all of yours if you slave all of mine" where only 1
server is under your administrative control?
David Botham
> -----Original Message-----
> From: bind-use...@isc.org [mailto:bind-use...@isc.org] On
> Behalf Of Kevin Darcy
> Sent: Monday, September 30, 2002 7:28 PM
> To: comp-protoc...@isc.org
> Subject: NOTIFY-triggered Auto-slaving (was Re: how to list ALL zones
of
> my master server)
>
>
> Jim Reid wrote:
>
> > >>>>> "Kevin" == Kevin Darcy <k...@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...
> 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).
>
Mark_A...@isc.org
If you want this write it up as a draft and submit it to
the IETF. The working group thought about this when we did
NOTIFY but left it as a exercise for the future. At the
time we were worried about security and theft of service
in addition to the meta data problem. We also wanted the
basic zone content updates to get through to RFC status and
not to get bogged down in debate over what metadata needs
to be tranmitted let alone how to do it.
TSIG can provide the security and through that protection from
theft of service. The rest is still a mess.
Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark.A...@isc.org
Kevin Darcy
Jim Reid wrote:
> >>>>> "Kevin" == Kevin Darcy <k...@daimlerchrysler.com> writes:
>
> >> 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"?
>
> Kevin> So are you objecting to the suggestion as it has been
> Kevin> stated, or are you objecting to what you perceive might be
> Kevin> the "logical next step" of the suggestion?
>
> Both. I'm objecting to a protocol being corrupted and abused for
> things it was never designed to do.
In general terms, NOTIFY was designed as a way for masters to tell slaves
that a change has occurred to a zone. The transition from non-existence
to existence is a change is it not (watch out: I have a degree in
Philosophy so if you want to debate the finer points of ontology, I can
do so until the cows come home)? While this specifc *application* of
NOTIFY may not have been intended, it seems an entirely reasonable use of
the mechanism, not a "corruption" or "abuse". But, I see that in your
text below, you seem to be (baselessly) assuming that some very
intrusive, possibly not-downwards-compatible protocol changes would be
necessary to support this. If I thought that, maybe I'd object too.
Perhaps when you realize that the proposal can be implemented without any
protocol changes, you'll reconsider your position.
> >> Well for starters the NOTIFY protocol was not intended to do
> >> such a thing.
>
> Kevin> True, but so what? This mechanism would in no way impede
> Kevin> the intended function of NOTIFY.
>
> Oh yeah? How do you figure that out? If NOTIFY is to be abused for
> automatic zone slaving, presumably some header bit -- which one? -- or
> extra RR in the packet would be needed to tell the server to slave
> some zone instead of treating the packet as a regular NOTIFY.
There you go making wild assumptions again. What's wrong with a simple
"if you don't slave this zone already, and you're configured to slave
every zone for which machine foo.example.com is master, then (assuming
the NOTIFY was verified as coming from foo.example.com) start slaving the
zone from foo.example.com using your configured defaults for the other
metadata"? No header bits required. No protocol change required.
> That
> means a protocol change. Which is an impediment to the intended
> purpose of NOTIFY. Or if the protocol remains unchanged, it implies
> some extra config file goop to tell the server which NOTIFYs mean
> "NOTIFY" and which mean "add this zone". [Hey, what about "remove this
> zone?"]
[Hey, what about it? Zone removal is outside the of scope of the
proposal. Is this another one of your straw man "logical next step"s? If
I were to automate slave-zone removal, I'd probably base it on whether
the zone has expired or not, or whether zone transfers have been failing,
not on NOTIFY at all.]
> That would require as much admin effort as just adding the
> zone{} statements in the first place.
No, the admin effort is much less, because you just configure "slave
everything from foo.example.com" *once* and never have to configure
anything else for those slave zones to start popping up indefinitely
(unless one adopts the probation/promotion alternative proposal, but
that's only for super-paranoid types).
> >> 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?
>
> Kevin> It's not a "corruption". I repeat: this mechanism would in
> Kevin> no way impeded the intended function of NOTIFY.
>
> Yes it does. How would a name server be expected to distinguish
> between a regular NOTIFY as defined in RFC1996 and one which means
> "slave this zone if you don't already slave it"?
Already addressed above.
> And what happens if
> the intended slave server can't or won't slave the new zone it's been
> told to serve? How does the victim server get that message back to the
> source of the NOTIFY? Or is that something to just not bother about?
If that's an issue, it's an issue *regardless* of whether NOTIFY is used
as a trigger or not; in fact, it's an issue *whenever* a slave is or
becomes "lame", i.e. is (mis)configured to not be or no longer be slave
for a zone, which can happen any number of ways. The NOTIFY RFC appears
to be mute on this point: it only specifies NOERROR NOTIFY responses, and
only when everything is copasetic. If you think there should be a
mechanism within NOTIFY -- or some other extension to the DNS protocol --
for (non-)slaves to signal masters that they are misconfigured for a
zone, then feel free to propose same. But this issue isn't unique to
NOTIFY-triggered slave-creation, so it doesn't detract from the proposal.
> Kevin> As for this hypothetical "DNS provisioning protocol", I
> Kevin> agree it would be a useful thing to have. But there is no
> Kevin> proposal, no working group, no development in this area.
>
> So go ahead and start one. This would be a more productive thing to
> spend time on than advocating to cruft unsightly warts on to the
> NOTIFY protocol.
NOTIFY-triggering would be a short- to medium-term solution. A
"DNS provisioning protocol" would be a long-term solution. And the
"unsightly warts on [...] the NOTIFY protocol" are only in your
imagination. As far as I see, there are no protocol changes required for
what has been proposed thusfar. If TSIG-signing NOTIFYs is _ipso_facto_ a
protocol violation, then apparently BIND is already committing that
violation:
203. [func] notify and zone soa queries are now
tsig signed when appropriate.
> Kevin> For an extra helping of paranoia, perhaps the newly-created
> Kevin> zones could be put on "probation" for a while until a human
> Kevin> actually "promotes" the zone to a full-fledged slave
> Kevin> zone. If not promoted within a certain (configurable) time
> Kevin> period, the zone would "expire", and never be auto-created
> Kevin> again absent human intervention. Even if the time period
> Kevin> were set as low as 24 hours, for a busy hosting outfit a
> Kevin> once-a-day "promotion session" would still be a win over
> Kevin> having to log into the slave(s) multiple times a day to
> Kevin> edit named.conf (especially if the promotion operation
> Kevin> could be done remotely-yet-securely, e.g. through rndc).
>
> This is too silly for words. The human who does this "promotion" could
> just as easily add new zone{} statements to named.conf, obviating the
> need for this bizarre proposal.
Well Jim, I don't know about your customers, but mine want new zones
available *immediately* (if not yesterday) with full redundancy. With
NOTIFY-triggering, the zones would be slaved almost instantaneously, and
if there is a "promotion" step it could be performed only daily, weekly,
monthly or whatever the administrator configures. So the administrator
would achieve economy of scale; they wouldn't have to be in there
constantly updating named.conf, only the occasional promotion session
where they could "finalize" several (if not hundreds) of zones at once.
And, remember, the whole probation/promotion thing would only be for
super-paranoid sites. In reality, I think most sites would be happy for
this to be completely automated, as long as the NOTIFYs were TSIG-signed,
thus providing reasonable (if not perfect) protection against spoofing.
> Another point: as I'm sure you realise, there's a lot more to serving
> DNS zones than updating config files. Anyone who does this job
> responsibly will already be doing a lot of provisioning for that zone:
> capturing contact details for the zone's admin and technical contacts,
> keeping track of contract expiry and renewal dates, making sure the
> domain name has been approved by the competent authority (eg corporate
> naming standards), determining which name servers to use, logging and
> auditing change requests, documenting the name servers that are used,
> etc, etc. So the task of adding the zone{} statement is just a one
> small part of the overall process. And one that can be automated too.
So why are you fighting so hard against automating it?
- Kevin
Kevin Darcy
Mark_A...@isc.org wrote:
> If you want this write it up as a draft and submit it to
> the IETF. The working group thought about this when we did
> NOTIFY but left it as a exercise for the future. At the
> time we were worried about security and theft of service
> in addition to the meta data problem. We also wanted the
> basic zone content updates to get through to RFC status and
> not to get bogged down in debate over what metadata needs
> to be tranmitted let alone how to do it.
>
> TSIG can provide the security and through that protection from
> theft of service. The rest is still a mess.
OK, Mark, try taking off your protocol-designer hat for a moment and put
on your BIND-implementor hat. Given that TSIG-signed NOTIFYs are now a
reality with BIND, without any protocol changes, RFCs or IETF/IESG action
required, and therefore security is no longer the issue it once was,
would it not be a reasonable feature request to have a BIND instance
automatically slave zones upon receipt of a TSIG-signature-verified
NOTIFY, if configured to do so by the administrator of said BIND instance
and using metadata provided, perhaps in template form, by said
administrator? It's a "halfway measure" only in the sense that we don't
have a whole protocol by which a master can communicate metadata to the
slave -- as you said, that's "still a mess" -- but just because we can't
do *everything* does that mean we should do *nothing* to automate
slave-creation? Is this an all or nothing proposition? I don't think so.
I know there a lot of DNS admins out there -- I'm one of them, since this
is one of the few things I haven't automated yet -- who want to eliminate
the drudge work of constantly editing named.conf files, and would eagerly
embrace a less-than-comprehensive solution to the problem.
- Kevin