On Fri, Apr 4, 2014 at 8:31 AM, Petr Spacek <[email protected]> wrote: > Hello, > > Let me sum up the discussion and document the compromise for archaeologists:
Thanks. > Approach A > ========== > One approach is to do nothing in stub resolvers and rely on validating > resolvers or application logic. > This approach was mentioned by Paul Wouters <[email protected]>, Prasad > Pandit <[email protected]>, Carlos O'Donell <[email protected]>, Olafur > Gudmundsson <[email protected]>. Also, Michael Richardson had some comments about uninformative error/timeout handling when the application doesn't do its own DNSSEC validation. There are solutions to Michael's problem, such as running an in-app resolver when the user wants detailed error information. > It seems that the main concern about AD bit stripping in stub resolvers is > compatibility with existing applications which rely on AD bit: We should want fail-closed semantics. I very much prefer having a caching validating local server. I don't mind making people (and configuration apps) explicitly set a global in /etc/resolv.conf to disable AD stripping. I'd provide two settings, one to disable AD stripping IFF the only nameserver is ::1, and another to disable AD stripping in all other cases. > After further discussion, it seems that pwouters is okay with AD bit > stripping in stub resolver if it is explicitly requested by a calling > application. (E.g. by special resolver initialization.) Again, we need fail-closed semantics. > Approach B > ========== > The other approach is to do AD bit stripping in stub resolvers by default. > It was proposed to add system-wide setting for this (e.g. to resolv.conf) > and default to "strip AD bit unless admin configured something else". > > This approach was mentioned by Petr Spacek <[email protected]>, Simo Sorce > <[email protected]>, Viktor Dukhovni <[email protected]>, Tony Finch > <[email protected]>, James Cloos <[email protected]>. > > Naturally, application has to be able to do run-time check that it is using > a library with this new behavior to avoid running in unsafe environment. This might be done at install time, or first-run time if we commit to never removing this feature once it's added and/or if we provide an interface for notifying applications of removal of this feature. This approach means not having to extend APIs. However extending APIs is probably OK enough I think, given that we have relatively few DNSSEC-capable apps today. > Next Steps > ========== > Define what is yet not defined: > - System-wide configuration format (e.g. modify resolv.conf vs. add a new > file) The former. > - Propose specific API changes for major DNS libraries (glibc, maybe ldns > and co.) See below. > - Prepare recommendation for application developers how and when to use a > new API Sure. > Further discussion about implementation details will happen on mailing lists > related to the particular DNS libraries. For the res_init() API it'd be nice to have an agreed-upon extension. Where is that to be discussed, if at all? Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
