In message <[email protected]>, Paul Wouters 
writes:
> 
> Hi,
> 
> I've been part of a very long and heated discussion about the trust of
> the AD bit. I would like to hear from people here what they think.
> 
> I'm currently aware of two (non-dns utilities) applications that make
> security decisions based on "blindly" trusting the AD bit: ssh with
> VerifyHostKeyDNS=yes|ask and Postfix.
> 
> libreswan and strongswan are examples of applications that use libunbound
> for in-application DNSSEC validation to avoid needing to trust
> /etc/resolv.conf DNS servers for the AD bit.
> 
> First, let me list 4 items everyone seems to agree on:

Actually 2 is very much not agreeded apon by everyone.

> 1 Applications can either do dnssec validation themselves, or trust the
>    AD bit.
> 
> 2 It is undesirable that each application has its own DNSSEC validation
>    code, trust anchors and DNS cache.
> 
> 3 It is undesirable that applications blindly trust the AD bit when
>    resolv.conf points to another host as the AD bit could have been modified
>    on the network.
> 
> 4 In the ideal world tomorrow, each host has its own automatically
>    configured, perfectly working validing DNS server and resolv.conf can
>    be ignored or is always hardcoded with nameserver 127.0.0.1
> 
> Now for my question. Until we reach 4), what should we do with the AD
> bit in getaddrinfo() ?
> 
> A) strip the AD bit in struct addrinfo for "untrusted nameservers". A new
>     configuration mechanism will allow white-listing nameservers and 127.0.0.1
>     will always be on the whitelist.
> 
> B) do nothing
> 
> C) Something else, please specify
> 
> Paul
> 
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email protected]

_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane

Reply via email to