FQDNs in masters-list (was: Help: Secondary for...)
kcd at daimlerchrysler.com
Tue Mar 13 02:09:03 UTC 2001
Brad Knowles wrote:
> At 1:14 PM -0500 3/12/01, Kevin Darcy wrote:
> > Um, yeah, so what? This is the *BIND* list, not namedroppers. It's
> > appropriate to discuss implementation details here. I'd like to see
> > signed-NOTIFY-based slave auto-configuration someday added to BIND, and
> > I'm eliciting comments on whether folks would find this a valuable
> > feature or not. I assume your answer is "no" (?)
> You can't propose protocol changes to solve a problem specific to
> BIND. Use BIND-specific mechanisms to solve problems specific to
> BIND, and use protocol changes to solve problems in the protocol.
> But never the twain should meet.
The ability to sign NOTIFYs is a *feature*, not really the solution to a
"problem", _per_se_. It falls under the general rubric of "improving the security
of DNS". Having said that, the fact that signed NOTIFYs could be used by BIND or
some/any other DNS implementation, to implement slave auto-configuration is just
an additional benefit that could be derived from the protocol change.
> > Well, I don't know about "unsigned content within a zone transfer". If
> > the zone transfer itself is signed, is that not sufficient?
> Not unless you can guarantee that signing the zone transfer
> itself is sufficient to guarantee freedom from replay attacks.
Does signing each individual record in a zone transfer really buy one any more
insurance against replay attacks than signing the whole zone transfer _in_toto_?
Seems like there's a window for replay attacks in either case, but the window
would be small enough that it wouldn't be more than the normal cache persistence
of the records in the zone anyway...
In any event, it seems to me that replay attacks aren't likely to garner a
potential hacker any useful advantage anyway, since slaves will reject a zone
transfer with a serial-number equal to or lower than what they already have. The
only window of vulnerability would be if one was undergoing a serial-number reset
More information about the bind-users