Hi, Nikos: Nikos Mavrogiannopoulos wrote: > The D-BUS interface is not really necessary because DNS provides > already this functionality. What we need is a convention for > applications in the system to discover the local trusted (for dnssec) > nameservers.
What do you mean by "local"? A nameserver listening on localhost, or only a nameserver on the local network? > My attempt to use c-ares for dnssec resolving would have the same effect > as the ones you mention and is much cleaner and straightforward than > D-BUS. However, it is blocked by the fact that there is no commonly > acceptable convention for reading the trusted nameservers. My current > solution was to use /etc/resolv-sec.conf, but it is pretty much > arbitrary and that's why c-ares upstream blocked it. If Debian would set > such a convention, I think it would allow software use DNSSEC easier. > > https://github.com/bagder/c-ares/pulls If I understand this pull request correctly, it only checks that the AD bit is set in responses; in the language of RFC 4033, that makes this a "Non-Validating Security-Aware Stub Resolver". libunbound, OTOH, is a "Validating Stub Resolver" (it can also do full recursion if no forwarders are configured). A tool that uses libunbound can guarantee that the result is cryptographically authentic, to the limits of the integrity of the local system. So, I disagree with you if you are saying that trusting the AD bit without validating from a nameserver on the local network (even if it has been marked as "trusted" by local policy) has the same effect as validating on the endpoint (whether it be by a trusted process or by a nameserver bound to a privileged port, etc.). Maybe better than a D-BUS service would be DNS transport over an AF_LOCAL / SOCK_DGRAM socket; that can also guarantee that validation happens on the local system by a trusted process. Though, I wonder why danetool / libdane must perform the DNS lookup itself. Couldn't it also have an interface for accepting fetched TLSA records that have already been validated by an external tool? (I see that it can fetch certificates from remote servers, too, so I guess it wants to be an all-in-one tool.) E.g., unbound-host can securely fetch TLSA records: $ unbound-host -v -f /usr/share/dns/root.key -t TLSA _443._tcp.www.nic.cz _443._tcp.www.nic.cz has TLSA record 3 1 1 AA7B93DAAB084536530BD3256E9CEFF4557CB43512640F7AB64487DC9CA14FAB (secure) $ Also, unrelated to this discussion, I notice that gnutls hardcodes the path to the root trust anchor file at compile time: AC_ARG_WITH(unbound-root-key-file, AS_HELP_STRING([--with-unbound-root-key-file], [specify the unbound root key file]), unbound_root_key_file="$withval", if test "$have_win" = yes; then unbound_root_key_file="C:\\Program Files\\Unbound\\root.key" else if test -f /var/lib/unbound/root.key;then unbound_root_key_file="/var/lib/unbound/root.key" else unbound_root_key_file="/etc/unbound/root.key" fi fi ) This is not right; a buildd environment won't have a running unbound daemon and thus won't have a /var/lib/unbound/root.key file, and /etc/unbound/root.key won't normally exist on a Debian system. (There is a package in Debian that ships the root trust anchor, though: dns-root-data.) -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
