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.