From the linked message: 1) DNS-Architecturally speaking, this statement is incorrect:
*Local validating resolver is strongly recommended.* What is needed is: *Local validator is strongly recommended.* Well, this is better: *Local validator is required.* Or "local validation is required in order to assess the level of trust in what is received”. If the goal is being able to trust what is received, you have to have validation, it’s not just a good idea. 2) /etc/sresolv.conf. - System-wide configuration format (e.g. modify resolv.conf vs. add a new file) In 1998 I used “/etc/sresolv.conf” in the first prototype validator. It had configuration lines for trust anchors and all the rest of /etc/resolv.conf. There’s no reason you can’t reuse the existing file or soft link (/etc/resolv.conf -> ../var/run/resolv.conf) 3) As far as AD bit stripping…. The question to ask is whether you trust the stub resolver’s (set of) sources or not. If you trust the sources for all things other than DANE, why not trust them for DANE too? Conversely, if you don’t trust them for DANE, why trust the sources for anything? One can view DNSSEC as a standalone application. The “server” is the dnssec signer, the “client” is the validator. Those two act like IPSEC tunnel endpoints. What goes in one comes out the other unmolested. The fact that “below” the DNSSEC plane is plain old DNS is irrelevant. I could take the results of the signer and FTP them to the validator, rsync them, etc. DNSSEC only allows the validator to determine if what it got was produced by an authorized(-by-the DNS-zone-administrator) signer, operated in an authorized manner. It is (or was) possible to tweak the DNSSEC to have the signer be in the hands of whomever is responsible for DANE but not the DNS. That would be by attaching RRSIGs generated by keys that are identified as DANE-not-DNS. (This is in the concept, don’t know if it is in the software anymore.) On Apr 8, 2014, at 7:38, Petr Spacek <[email protected]> wrote: > On 4.4.2014 00:42, Paul Hoffman wrote: >> On Apr 3, 2014, at 2:50 PM, Andrew Sullivan<[email protected]> wrote: >> >>> >On Thu, Apr 03, 2014 at 05:39:58PM -0400, Suzanne Woolf wrote: >>> > >>>> >> operated on Internet networks. This will include root zone >>>> >> name servers, TLD name servers, name servers for other DNS >>>> >> zones, iterative DNS resolvers, and recursive DNS resolvers. >>> > >>> >Is there a reason to call out these particular functions, or not to >>> >include something like, "or any other resolver or server functioning >>> >as part of the global DNS"? I'm just worried, for instance, that >>> >stubs don't appear there, even though there might be advice I can >>> >imagine the WG providing. >> +1 to at least calling out stub resolvers, but Andrew's non-list formulation >> is better. > > I agree that including stub-resolvers and other DNS-related software sounds > like a good idea. > > There were long threads about DNSSEC handling in stub-resolvers on dane-list > [0] but dnsop seems like a better place to discuss this matter. > > Note that this discussion is not over so we can move it to dnsop if dnsop > agrees. > > [0] http://www.ietf.org/mail-archive/web/dane/current/msg06658.html > > -- > Petr Spacek @ Red Hat > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
