Nikos Mavrogiannopoulos wrote: > On Wed, 2015-03-25 at 14:00 -0400, Robert Edmonds 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? > > It depends how the network is organized. It can be a server on the > localhost, a server on a different VM, or container.
How does a server on a different VM count as local, even if running on the same chassis? (Also, you do exclude across a physical LAN/WLAN/etc. from your definition of local, right? Just making sure.) > That is system policy applications cannot and should not enforce. I disagree. What's the use case for easily allowing, as a configurable policy, delegating an application's cryptographic validation to a server that may be off-host? > > 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. > > That's the same guarantee of you connect to unbound via localhost. It is > no different than connecting via unix sockets or using the API of > libunbound. I agree that non-validating stub resolution via localhost or AF_LOCAL to a validating server running on the same host is the same guarantee as calling libunbound -- validation takes place on-host, if not in the same process, then by a privileged process running on the same host. But your c-ares pull requests (#20, #21, #22) don't guarantee that validation takes place on-host (i.e., via localhost/loopback). > > 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. > > I don't see any difference of AF_LOCAL with the loopback interface. Nor do I, but there is no guarantee that servers listed in resolv.conf (or resolv-sec.conf) are on the loopback interface. -- 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
