On 27.2.2014 18:01, Paul Wouters wrote:
On Thu, 27 Feb 2014, Petr Spacek wrote:
Now we need to discuss 'a temporary solution' for the case where a
validating resolver is not available for whatever reason.
I don't agree with this premise, but those applications can be changed
to use (most error handling removed for clarity):
/* one time setup */
dnsctx = ub_ctx_create(); /* create unbound resolver context */
Please correct me if I'm wrong but I'm afraid that this snippet effectively
bakes a security policy to applications:
ub_ctx_hosts(dnsctx, "/etc/hosts") /* emulate POSIX */
ub_ctx_resolvconf(dnsctx, "/etc/resolv.conf") /* use nameservers from
resolv.conf */
ub_ctx_add_ta(dnsctx, rootanchor); /* root key auto-updates via
/var/lib/unbound/root.anchor */
ub_ctx_set_option(dnsctx, "dlv-anchor:", dlvanchor); /* activate DLV */
How can I install my own trust anchors? (E.g. I have internal zones and I want
to use DNSSEC for them...) How can I disable DLV on system-wide level? All
this should be system-wide configuration otherwise it will create problems for
tightly controlled environments.
This has the same effect as stripping out forged AD bits, except real AD
bits survive. It uses whatever nameservers the system has in
/etc/resolv.conf. It supports overrides in /etc/hosts. It does not
require glibc modification. It does not require various applications
read new keywords in resolv.conf or new config files. It has no race
conditions. It's a great band-aid until "tomorrow".
And possibly, the getdns API has an even simpler way of doing this.
I agree that new DNS API is a great idea, I have said that many times already.
Is this really too hard to do today for those old applications that need
to be fixed and for the new applications you will write tomorrow?
Will you patch every application doing TLS to link with libunbound? (Upstream
developers are always happy to accept patches introducing new dependencies.)
Are you going to convince OpenStack people (accepting only pure Python code
and nothing else) to use this?
Please see the other branch of this thread, I will reply there about crypto
libraries.
--
Petr^2 Spacek
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
