Bug#733295: gnutls-bin: please compile GnuTLS with DANE support

[Nikos Mavrogiannopoulos]

On Tue, 2015-03-24 at 18:52 -0400, Robert Edmonds wrote:

>  4. Design and implement a D-Bus interface for securely retrieving
>     DNSSEC-validated records that have been validated *on the system*.
>     Patch daemons (Unbound, BIND, et al) to answer to this interface.
>     Patch clients (libdane, et al) to request records using this
>     interface.
> 
> This is sort of analogous to the security you would get in having a
> plain validating DNS server listening on localhost and a "nameserver
> 127.0.0.1" line (and no others) in /etc/resolv.conf and requiring the
> "AD" bit in responses, but the big advantage would be that the security
> guarantee from doing DNSSEC validation directly on the endpoint is
> guaranteed by the definition of the interface, and not from the
> happenstance of local configuration.
> This would:
> 
>  * Avoid licensing issues.
>  
>  * Avoid extra TLS/crypto related library dependencies in clients.
> 
>  * Allow other validators that are not written in the form of a library
>    (e.g., BIND, PowerDNS) to be used with clients that need
>    DNSSEC-secured answers.  And for validators that do have a library
>    API, do you really want to have each client have its own #ifdef mess
>    to support multiple APIs?
> 
>  * Allow system-wide, not just process-wide caching.  (Even if your
>    direct-libunbound client is pointed at a resolver on 127.0.0.1 that
>    has the answers in cache, it still may need to do many send/recv
>    system calls to obtain each needed record, because DNS can only
>    return one answer at a time per query/response.)
> 
>  * Insulate the client from needing to know how to configure the
>    DNSSEC-lookup library.  (E.g., remote DNS servers, trust anchors,
>    etc.)

Hi,
 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. 

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

regards,
Nikos