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 [
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
