Validating zones as a slave? (Fw: [DNSOP] I-D Action: draft-ietf-dnsop-root-loopback-04.txt)

Paul Vixie paul at redbarn.org
Wed Sep 16 11:28:19 UTC 2015



Evan Hunt wrote:
> ...
>
> Zone transfers always run over TCP and are almost always TSIG-signed,
> so they're fairly difficult to spoof in general. In this one
> particular use case, where you're locally slaving the root zone,
> there's no TSIG, so a DNSSEC verification step after the transfer
> could make some sense.  But, there being other ways to accomplish
> the same goal, it's probably not going to be a priority.

evan, i think that every root name server whether IANA or Yeti or
private, would want different behaviour than is currently extant. that
is, we'd like what tony finch said, don't replace the zone on a
secondary server unless the new zone is valid by its own included DNSSEC
metadata. this means a failure to transfer won't invalidate the existing
zone, even if expiration of the zone or its signatures may lead to that
outcome later on for other reasons.

BIND9 is ideally constructed so as to permit such an extra step. one way
to do it is with after-transfer hooks, something i'd added to BIND8 late
in the game that i don't think BIND9 has. another way to do it is to
institutionalize this process rather than using "views" to do it as
described in the dns-root-loopback draft by kumari/hoffman. in some way,
i hope ISC will lead on this matter, such that a later I-D on the same
topic can be well informed by operational practice.

-- 
Paul Vixie


More information about the bind-workers mailing list