Hello,
please comment on the following proposal. Paul and Viktor are most active in
this discussion but we would like to hear opinions from other experts!
Let's agree on the very basic principle, please do not recommend particular
libraries etc.
The Goal
========
On 28.2.2014 00:09, Viktor Dukhovni wrote:
>> On 27.2.2014 22:26, Viktor Dukhovni wrote:
I want the AD bit to be more than blind faith.
(This means AD bit as seen by applications in responses from generic DNS API.)
Long-term solution
==================
Paul Wouters pushes hard for validating recursor on each host. Viktor and me
agree with that:
So *if* there is a local resolver and it is the only one used,
great! No need to disable the AD bit. If there is not, perhaps
"failing safe" is sensible.
However, we want to find some intermediate solution deployable today.
It may be enough to design systems that default to local resolvers,
and users who change that are free to shoot themselves in both feet.
Proposal for short-term solution - please comment
=================================================
All names are completely "random". Please propose better names and/or semantics.
1) Add a new boolean to /etc/resolv.conf:
options resolvers-trusted
- If present, this option states that "admin ensured that recursor is
trustworthy and the communication link between recursor and stub-resolver is
secure".
- If present, the AD bit will be passed from recursors to applications as-is.
- If not present, the AD bit sent to a applications will be always 0.
- E.g. the option will be present on a system with locally running Unbound.
- E.g. the option *will not* be present on thin client, compute node in data
centre, a random laptop installed today with default configuration etc.
Objections:
- There is a chance that dhcp client copies "options" from old resolv.conf to
new one. In that case simplest variant "options resolvers-trusted" is insecure
if one configured e.g. local trusted recursor and DHCP client was started
after that.
- Many applications mess with resolv.conf so the new boolean should be
somewhere else. E.g. /etc/resolv.trusted.
- Because of the first objection, the file /etc/resolv.trusted should contain
explicit whitelist with IP addresses of trusted recursors. That lowers the
probability that admin sets option "resolvers-trusted" to /etc/resolv.trusted
but some application (like DHCP client) will change name servers in
/etc/resolv.conf.
2) Add a function call for run-time check (for library users):
boolean dns_resolvers_trusted(resolver);
- TRUE if admin declared resolvers as trusted. AD bit is unchanged.
- FALSE otherwise. AD bit is always set to 0. Applications can detect that AD
bit masking is enabled.
- If the function is not defined then DNS library doesn't support AD bit
masking as described here.
Naturally, this can be replaced by any other mechanism for run-time checks if
a library in question has such mechanism already.
3) Usage from applications:
- Call run-time check:
/* WARNING! This call can't be skipped: It ensures that your DNS the library
supports the new behavior. */
dns_trusted = dns_resolvers_trusted(resolver);
if (dns_trusted)
Enable code depending on DNSSEC
else
Fallback
- Decide if you want to use the data from DNS or not:
dns_query(resolver, query, answer);
if (answer->ad_bit)
Use data from DNS (answer->data)
else
Fallback
Please add what I have missed, what is wrong etc.
Thank you very much for your time!
--
Petr^2 Spacek
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
