On 27.2.2014 21:04, Petr Spacek wrote:
For example current software like Postfix or OpenSSH client will
'just work' without any change. AD bit will be handled in special
way only if the resolver library is initialized with the new call.
As the developer of the Postfix DANE interface, I'd rather Postfix
AD bit handling were subject to default system policy, and would
ask the administrator to set system policy accordingly. Once APIs
for querying the stub-resolver behaviour (AD suppressed or trusted)
become widely available, Postfix will start using them to sanity
check its TLS policy settings (can't use DANE when stub resolver
suppresses AD support).
I 100 % agree with your point of view.
The problem is that our glibc maintainer explicitly refused to change default
behavior (i.e. mask AD bit until admin white-lists given resolver in
/etc/resolv.conf) because it could break some (potentially) existing
applications. That is a reason why we invented "init_trusted()" concept.
Could you give us some detailed thoughts about compatibility?
I guess that we will have the same discussion about compatibility again and
again with many upstream developers from many DNS libraries so any detailed
analysis will be handy.
I'm adding quote from our glibc maintainer:
>>>> Carlos O'Donell <[email protected]> wrote:
Consider a RHEL7 or RHEL6 system using the present meaning of
`nameserver' in /etc/resolv.conf, on a secure network with a trusted
recursive resolver using DNSSEC for some given domains. In this
configuration any application using the AD bit works as expected.
The system administrators ensured there was trust between the recursive
resolver and the client stub resolver. This is how a user might configure
their corporate network, and even better they might also use 802.1x
with no rogue or untrusted systems on their network.
If we release a z-stream or y-stream glibc that inverts the definition
of `nameserver' from trusted to untrusted (doesn't use EDNS0+DO for
a query, and clears the AD bit) then applications in such a configuration
as described above that rely on the AD bit forwarding may cease to
function correctly.
That is why I do not want to change the existing meaning of `nameserver'
and why we should not change any of the existing meanings of entries in
/etc/resolv.conf. Thus for compatibility I suggest adding a new option
`untrusted' for use by such applications as NetworkManager to put
untrusted DNS server (acquired from untrusted DHCP results) into.
Let me be clear though, if I didn't care about breaking customer
configurations, I'd make this change, but I think we would be doing
a disservice to our users by breaking valid existing DNSSEC uses.
--
Petr^2 Spacek
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
