[dnssec-deployment] DNSSEC deployment hurdles
marka at isc.org
Sun Aug 30 22:57:59 EDT 2009
In message <list-17987579 at execdsl.com>, Paul Wouters writes:
> On Mon, 31 Aug 2009, Mark Andrews wrote:
> >> I assume it only does this when it is aware there is no signed parent or D
> >> or when dnssec validation has not been enabled through the configuration f
> >> (though i think in the latter case it also no longer sets do=1)
> > Unless the QNAME matches a trush anchor's name, or you have explictly
> > stated that part of the namespace is secure, you can't know if the
> > answer to a particular query should be signed or not without rumaging
> Okay, so if we have a trusted key for tld. containing a DS for sub.tld.
> and we're sending queries to the nameservers of sub.tld. using do=1,
> we won't drop them and go without do=1. That's what I thought, but I
> wanted to make it clear, as Bert's explained do=1 removal did not make
> that clear when he said bind would drop do=1 in certain cases.
We don't track whether a delegation is secure or insecure as we
iterate. There is no need to do.
> I also thought bind no longer used do=1 when there was no need for it.
> Wasn't that the "DSL routers are broken" bug that was hit in Sweden?
No, named always initially sends with DO=1 unless it has been told
not too using server directives.
The problem was AD=1 in responses w/o DO=1. Note AD=1 w/o DO or
even EDNS was allowed back in 1999 (RFC 2535).
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the Dnssec-deployment