Replies inline, cutting out most of the quoted text for length. I want to stress the point that I *want* signed records available to the end user but we're not at a point where the infrastructure is there to do this.
Nothing crypto can bootstrap itself and be 100% secure. It is mathematically impossible. Complaining about that is like asking for a unicorn. You can ask as much as you want but it will not happen.
We can do better than RFC 5011. In the TLS world, operating systems maintain stores with valid root certificates. As CAs rise and fall, the root stores get updated, old software can connect to new CAs and things just keep working. While I won't say this process is perfect, TLS communication is essentially an OS function with Microsoft providing SChannel and a root store, Apple providing Secure Transit and it's root store, and most Linux distributions shipping TLS libraries configured to use a CA bundle file (Ubuntu has update-ca-certificates command for this purpose). Right now, for the KSK, the only mechanism for distributing root keys is downloading them from IANA or RFC 5011 if you're a DNS server of some type.
Hardware reset + trust on first use works reasonably well. That is essentially what lots of us do for WiFi.
The equivalent of
“dig +short dnskey . | awk ‘$1 == 257 { … }’ > tmp”
with sanity checking before moving into place.
I'll agree that this is likely better than the current situation with RFC 5011. However, this behavior should be standardized via RFC or at least a BCP. That being said, if we can do better, we should.
Furthermore, there is no standardized API for validating DNSSEC information outside of a DNS recursive resolver implementation (AD=1).
There is no standard resolver API. Posix doesn’t have one. getaddrinfo() sits above the resolver. That said there are a number of resolver implementations that are available and are compliant with STD13.
res_send(), res_search(), and anything else that returns the full answer.
bool ad = buf[3] & 0x20;
Yes, this is working at the level of the resolver.
res_* are a de facto standard; they're originally from BSD 4.3, and exist in one form or another in every major UNIX and UNIX-like distros. Granted, not all implementations support DO=1, but the API itself is very wide spread. Furthermore, the DNS client library is beside the point beyond being able to retrieve records and checking the status of AD. That being said, we're talking more about just the capabilities of the resolver.
I'm unaware of a library that I can drop into my code, does DNS for me on my behalf (with or without the system stub resolver), and compares it to a list of KSKs I know is valid. Even if said library *existed*, we'd just extend the number of places that breaks on a KSK rollover, and due to the previous paragraph, that's a *bad* thing.
If you want that, you can install dnssec-trigger. dnssec-trigger however causes additional load on both the root and intermediary servers by causing additional lookups to do DNSSEC validation.
Userland applications have no way of knowing if their DNS responses are going to a trusted source, most end users are just going to accept whatever their DHCP server tells them, and most recursive resolvers can't be trusted.
The point of doing DNSSEC in the app is that you do not have to trust the resolver. You can verify the answer yourself.
By the standard you set, checking the AD bit by itself is insufficient. I agree with you since recursive resolvers can lie as much as they want, so we need to handle the alternative. A large part of my research project time is categorizing recursive resolvers and building tools to understand them. Verifying RRSIG data requires having the root KSK beforehand or trust-on-first-use from the root, then having a complete set of DS/DNSKEY/RRSIG records from the root downward to the leaf node (or RRSIG/NSEC(3) for confirming a zone is not signed), being able to parse said records, perform the necessary crypto validation, and then verify that everything is kosher. Fine, I'm all for that but at a level that is entirely transparent to the application especially because it's a lot of work.
There are a number of DNSSEC capable libraries that can validate answers you get back from upstream.
This isn’t a matter of the technology not being available. It’s a matter of people not using it.
The problem is I need a library to validate the DNSSEC answer. That's the wrong solution. The correct solution is the operating system (or whatever you're using for DNS and sockets) should be doing this transparently when I tickle gethostbyname() and friends. Fixing an application at a time to validate DNSSEC is like subtracting one from infinity; we're not going to get anywhere like that (this is a point I've been trying to hammer in UASG in regards to "oh, just use this third party IDN library and fix every place your app uses domain names"). The way we fix this is we publish a BCP on how we should be doing secure DNS queries in 2019: do the query, and either request all the records we need, or use a mechanism like RFC 7901 CHAIN to get them in a single go. With broken resolvers that can't handle DNSSEC, skip them and recuse from the root as a last resort. Great, now that we have a BCP, we go to glibc, and write a patch that implements DNSSEC validation at the resolver level with a new flag to opt out by setting DO=0 (or CD=1 depending on your needs) and justify the change by pointing at that BCP. Boom, you've fixed it for all Linux distros. We go to Mozilla and add support to NSS/NSPR, boom, all Mozilla applications now do it correctly out of the box. Repeat for any other DNS resolver implementations. Apply necessary pressure to Apple and Microsoft to change their respective operating systems. Add DoT/DoH on top and we have a nice shiny secure DNS ecosystem. KSK updates can happen as part of standard security updates and all apps get fixed at once. Everyone wins. I'm not saying this would be easy or even as straightforward as I'm making it sound (I'm not naive, this would be an uphill battle all the way), but depending on application makers to fix their apps one by one to add DNSSEC validation is never going to work. It's 2019 and we've still got lots of things that go boom on pure IPv6 networks and that's been going almost 25 years now and that has a *lot* more incentive for developers than checking DNSSEC status in the application layer, especially since most developers aren't even aware DNSSEC validation affects them at all. Michael