Hello,
Let me sum up the discussion and document the compromise for archaeologists:
It seems that almost everyone agree that local validating resolver is the
best option.
People start to disagree when it comes to questions like "Is it feasible to
rely on a local validating resolver in the near future? How can applications
detect that a validating resolver is not configured and that DNS responses
can't be trusted?"
Aim of the proposal below is to enable applications to stay safe on systems
without a validating resolver.
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]>.
It seems that the main concern about AD bit stripping in stub resolvers is
compatibility with existing applications which rely on AD bit:
http://www.ietf.org/mail-archive/web/dane/current/msg06521.html
http://www.ietf.org/mail-archive/web/dane/current/msg06497.html
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.)
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]>.
viktor1dane thinks that compatibility concerns are not well-founded:
http://www.ietf.org/mail-archive/web/dane/current/msg06523.html
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.
Compromise
==========
*Local validating resolver is strongly recommended.*
- Introduce a new system-wide setting for AD bit stripping.
- Add a new flag or initialization function to stub resolver API. Resolver
behavior will depend on this new flag:
-- Old applications (not using the new flag or new initialization call): Never
strip AD bits. 100 % compatibility is guaranteed.
-- New applications (actively using the flag): Stub resolver will strip all
AD bits by default until admin configures some trusted name servers.
Applications using the new resolver flags will fail safe on systems with no
configured trusted resolver i.e. an application will request AD bit
stripping from the stub resolver and the AD bit will be stripped until the
admin configured a trusted resolver.
Next Steps
==========
Define what is yet not defined:
- System-wide configuration format (e.g. modify resolv.conf vs. add a new file)
- Propose specific API changes for major DNS libraries (glibc, maybe ldns and
co.)
- Prepare recommendation for application developers how and when to use a new
API
Further discussion about implementation details will happen on mailing lists
related to the particular DNS libraries.
Please speak up *now* if you have strong technical objections against the
high-level idea described above.
--
Petr Spacek @ Red Hat
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
