Simo Sorce <[email protected]> wrote: > On Fri, 2014-02-28 at 20:52 -0500, Michael Richardson wrote: >> Simo Sorce <[email protected]> wrote: >> >> For this reason, I think that applications should not set or depend >> >> upon the AD bit, even if the resolver is ::1. They either understand >> >> DNS(SEC), or they use an API call way more sophisticated than >> >> getaddrinfo() to do their connections. Java had the right idea, but >> >> the implementation and error reporting was very poor. >> >> > Nothing in this proposal prevents you from doing that for applications >> > you care about. OTOH forcing applications to a completely new API by >> > refusing this proposal on your grounds will guarantee less applications >> > will use DNSSEC. And DNSEC support will rapidly fragment making >> > system-wide management a lot more difficult. I think that prospect is a >> > much worse evil. >> >> If I understand what you are saying, you are worried that different >> applications will make up different DNSSEC APIs, and each application will >> have different controls.
> Yes this is the worry, getting to an unmanageable situation that will
> discourage people from using DNSSEC.
>> I am not opposed to centralized DNSSEC resolution (whether on the same
>> host,
>> or via a trusted channel). It's that I am dissastified with "SERVFAIL"
>> as the only indication of a problem...
> Understandable, but I have the impression this is a separate problem.
The only *API* that we presently have is built on top of resolv.conf which
makes use to *DNS*, and that API's only DNSSEC control is *AD*. So, it's not
as yet, a separate problem.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting for hire =-
pgp3MiN9Cam0J.pgp
Description: PGP signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
