Maintained by: NLnet Labs

[Unbound-users] Google Public DNS

Tony Finch
Wed Mar 20 15:17:22 CET 2013


Joe Abley <jabley at hopcount.ca> wrote:
> On 2013-03-20, at 05:55, Phil Pennock <unbound-users+phil at spodhuis.org> wrote:
>
> > Mind, I think that unbound's approach is sane and I'm happy it is as it
> > is, but still, if an application wants to _rely_ on DNSSEC, then it
> > should be setting the DO flag and checking AD.  This affects forthcoming
> > DANE support, for instance.
>
> I think if an application wants to _rely_ on DNSSEC, then it should be
> setting the DO bit and the CD bit, and doing its own validation.

I think it's OK to trust AD if the resolver is on the local host. However
checking that with the usual resolver API requires some fairly grotty
furtling around inside the res_state structure...

It's a bad idea for recursive clients to set CD because this makes
validation brittle if (for example) some of a domain's authority servers
have broken data. A validating iterative resolver can retry the query
against different authorities when it gets bad data; a validating stub
that makes recursive queries cannot, and if the upstream has cached
the bad data the client is stuck. Yes I know RFC 6840 says you should set
CD, but it seems wrong to me especially regarding "all DNSSEC data that
exists", which reminds me of QTYPE=* breakage with cached partial answers.

http://www.ietf.org/mail-archive/web/ietf/current/msg73417.html

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.