This was Daniel Bernstein's argument, back when he was doing djbdns, and I believe it got him kicked off the IETF DNS list (he was, in this one instance, correct; I'm still confused about why zone files are a part of the DNS standard).
(They're practically obsolete now, so there isn't much uncertainty about who had the better side of this argument.)
https://www.internic.net/domain/root.zone
I agree that they are optional, but I wouldn't go so far to say they're obsolete.
How someone reacts to him can reveal whether that person is someone who thinks they are smarter than they really are, a personality type that is common amongst software developers. These are the type of people who cannot admit when they are wrong, and will never admit that they are incompetent. Arguably, it is because of such people that we are drowning in crappy software, and even worse, that crappy software is popular.
IMHO, djb is on the side of the user, whether intentionally or not. djbdns allowed me, a user, to take control of DNS on the networks and computers I own. The philosophy of BIND at the time felt like "DNS is for DNS experts. We're experts. Do as we tell you."^1 I also learned nsd so I do use BIND zone file format. But I never became a BIND user.
1. I see a parallel in the context of "certificate authorities". Nothing wrong with "CAs" in theory but in practice, i.e., commercialisation of certificates and browser-centricity, the system reeks. Pay to play, or at least mandatory third party intermediaries, and generally user hostile.
If the goal of a committee member is merely to be included in the committee. Otherwise, if the committee is merely operating as a rubber stamp for every one of it's members proposals, then there may not be much productive value in remaining there. Apparently that feeling was mutual.
- lots of protocols like HTTP and SMTP that use ABNF and text,
- protocols like DNS, SSHv2, and TLS that use ad-hoc syntax and encoding,
- NFSv4 (which uses ONC RPC),
- protocols like XMPP that use XML
The IETF doesn't care very much about those details because by the time a protocol has been brought to them for standardization it's already too late to insist on radical changes unless those radical changes are necessary to make the protocol secure or otherwise viable on the Internet.
Hatred of ASN.1 is misplaced and has been extremely counter-productive. Hatred of BER/DER/CER and all TLV encoding schemes ever is fair (so let's adopt OER!). Hatred of ASN.1 has led to things like Protocol Buffers, which... uses a TLV encoding because... probably the designers didn't really take the time to understand what came before.
But I suspect -and keep in mind that I wasn't there- that for DNSSEC hatred of ASN.1 was only part of it, with the other part being a desire for proper name constraints[0] and trust hierarchy[1].
It does make sense that if the names we wish to authenticate are hierarchical in nature[2] then the PKI for it should use the same hierarchy. The only reason that the WebPKI isn't structured the same as DNSSEC is that historically the support for x.509 naming constraints wasn't there, then the business model of the WebPKI made all those on the inside not want to fix that. Now that we have Let's Encrypt the latter problem is going away, but the underlying issues remain.
This is where you and I part and disagree. You greatly dislike DNSSEC, while I greatly like it. You especially dislike DANE, and I especially want DANE. But it's nice to know that we at least agree on ASN.1 and x.509.
[0] x.509 has this, but it's ill-supported in WebPKI land.
[1] x.509 also has, kind of[3] but which, again, WebPKI does not.
[2] DNS naming is strictly hierarchical, though one can be forgiven for thinking that the com. zone is just one big flat swamp as it really is, but it's not the whole of the DNS.
[3] Well, in x.509 the hierarchy of CAs is based on x.500 naming, which is just not appropriate for a web where URI authority names are DNS names (to say nothing of what a disaster x.500 naming is). There's alternative issuer names, which includes dNSName, but once more, the issue is how widespread the support for those is.
Forking implies a problem in one or more areas:
- governance
- usability (documentation and examples)
- potentially NIH-syndrome
protobufs, capnproto, flatbuffers, thrift, msgpack, erlang terms, BSON, java class files, and more exist to scratch itches that are not universally scratchable. You can't argue with the readability, portability, simplicity, or usability of JSON.. although you can argue with it's low density and parsing cost.
What's missing generally in computer science, software engineering, and systems engineering is standardization down to a minimal, feature-complete subset of interchange formats, protocols, and APIs in the spirit of professionalizing and standardizing the industry with trusted conventions. The issue has been raised many times over the past 60 years, but at some point, there needs to be more than the rare bird of "professional engineering" licensure and too common and useless A+ certifications.
I like DNSSEC and DANE because the combination adds another security layer to corroborate what PKI says. If browsers adopted it, it would be widely deployed to web-facing services. Like GPG, it has a UX problem and is a PITA to setup. (Sadly, a major DNSSEC multi browser extension effort shutdown.) I thought we were pro defense-in-depth rather than less security, so I don't understand the hate DNSSEC receives because it's not an alternative so much as a secondary trust-supporting mechanism.
Disclaimer: I run PKI at home where every machine has 802.11x certs, every "intranet" has a cert from an intermediate cert, and every service like vSphere has its own subordinate signing cert. I keep meaning to migrate over to FreeIPA with Dogtag.
Hah, the joke's on you: ASN.1 has JER, which is the ASN.1 JSON Encoding Rules :)
So you can specify JSON schemas in ASN.1 syntax, which means that you could transcode from any of the other ASN.1 encoding rules, which include:
- BER/DER/CER (TLV encodings)
- OER/PER (like XDR, but with one octet alignment)
- XER (yes, the X is for XML -- XML Encoding Rules)
- GSER (a pre-JSON JSON-like encoding rules for
ASN.1 invented at IETF)
- and other ERs that are proprietary
- and any ER you care to create, which could just
be bindings of other encoding schemes like
Flat Buffers or anything else you like.
I've been wanting an XDR-based encoding rules...
- benefited from existing ASN.1 modules
- benefited from transcoding
- benefited from existing ASN.1 compiler codebases
> I like DNSSEC and DANE because the combination adds another security layer to corroborate what PKI says. If browsers adopted it, it would be widely deployed to web-facing services. Like GPG, it has a UX problem and is a PITA to setup. (Sadly, a major DNSSEC multi browser extension effort shutdown.) I thought we were pro defense-in-depth rather than less security, so I don't understand the hate DNSSEC receives because it's not an alternative so much as a secondary trust-supporting mechanism.
I agree with this, though I'm not sure what is the antecedent of "it" in "[l]ike GPG, it has a UX problem..." -- could be DNSSEC, but it could also be PKI! :)
Nothing about DNSSEC precludes the addition of CT, and it will eventually happen.
DNSSEC w/ query name minimization means that any zone that wishes to MITM you has to potentially make the decision without first knowing what your target domain is, or even who you are (obviously this last depends on context), and the more indiscriminate they are in their MITM activities the more likely that they'll be caught. That's a big deal, and something WebPKI can't offer -- WebPKI only has CT to offer for mitigating the MITM power of CAs, and CT depends on people auditing the logs.
Also consider TdR of OpenBSD and OpenSSH has been polarizing but impactful.