It isn't a problem that someone off the street can't make sense of that, since it's a format that is an internal detail of a complicated tool. Someone off the street isn't expected to understand that: There's a plethora of tools that lets them enter stuff in other formats, and a plethora of web frontends.

What they do need to understand, though, to do anything beyond the extremely trivial, is the DNS data model, and the Bind style zone files reflects that data model extremely directly, so almost whatever they end up with doing, they will sooner or later come across something that may remind them of the zone files. And I get that is a lot of what causes people to be concerned about Bind zone files.

As I pointed out, there are lots of DNS servers where you won't see a Bind style zone file ever, and you don't need to require configuration to be done via a file at all. Djbdns is one of the former. ldapdns is one of the latter - that exposes DNS entries pulled out of an LDAP server. But both will be similar in structure because they map to the same data model.

The only thing you will achieve by devising a format like what you describe on top of DNS is drive people crazy, because they now need to learn a format that does not map easily directly to the DNS data model (if it does, it will appear very similar to zone files and will be pointless).

I've written a DNS server, that was used for a registrar platform (I co-founded the company that ran ".name"), and I didn't use zone files, but the data was still mostly the same.

If you want to change that, beyond the extremely superficial (e.g. renaming "MX" to "mailserver" or similar) that will only confuse people communicating with those using the original names, you'd need to start lower:

With the DNS data model and wire format. Good luck with that - there are trillions of dollars hinging on DNS working these days, and a lot of design decisions in DNS follows directly from real-life constraints that are not going to change.

They are simple: The data must be small - if records are too large for a single UDP datagram, it slows things down instantly. A DNS record consists of a label, an address family (can usually be omitted, as almost everyone just uses "IN"), a resource type (A,CNAME,MX etc. - you could rename those in your format), a TTL (which can usually be left out to use the default), and a resource type specific data field which is usually a string, label or IPv4 or v6 address (obvious exceptions: MX, which includes the priorty, and SOA).

You could possibly drop the address family, but as I pointed out, "everyone" just uses IN anyway, and most software will default to that if you leave it out. You can rename the record types to something "friendly", but you don't need to change internals of the software for that - just add a mapping to the UI of various tools - these query types are mapping to byte values internally in DNS servers anyway.

So what do you think you'd achieve? What can make DNS more understandable without breaking functionality people depend on?

> To use a word mentioned earlier, I believe code should be trivial, as trivial as reading a road sign.

Not going to happen, because code implements real world requirements, and many real world requirements are far more complicated than reading a road sign.

You can write a DNS server that is simple to understand for a programmer, though - DNS is not all that complicated. But then you don't need to mess with the DNS data model - it takes little effort to learn enough of it that zone files is not the problem. It took me less than a week to write my first fully functional DNS server without ever having looked at the RFC's before.

If you want to tackle unnecessary complexity, look somewhere else, like IMAP (or get people to stop using SOAP...) - now there is ridiculous complexity for no good reason (there are reasons, they just aren't good)

> Why should only l33t hackers be able to understand the full stack?

Sometimes because it often takes a huge amount of basic knowledge about the domain to even understand what people are talking about.

But you don't need that to understand DNS. Seriously.

Read RFC 1034 and 1035. Equip yourself with "tcpdump", "dig" and or "nslookup". Write some DNS encoding and decoding routines based on the data in RFC 1034. Run tcpdump and do capture some queries that you carry out via dig or nslookup. Test your encoding and decoding routines to see that they match based on the dig input/output and captured packets until you have them working.

Then write a simple authoritative resolver based on the rules in the RFC's (authoritative resolvers are simplest because you are only answering based on "I know this, it's in my local data set", as opposed to recursive resolvers that have to know when it is right to cache, when it is right to forward requests, who it should allow recursion for, and [these days] how to avoid being part of a DNS amplification attack unwittingly). That isn't much more complex than: Wait for incoming query; parse query; extract name it is asking for; if it is a name your server should serve, return the data you have for that name, otherwise return an error (handling corner cases will make it a bit more complex, such as handling fallback to TCP).

If you have any prior network programming experience, this should be no more than a week of coding if you keep things simple. If you're experienced, you might even have something basic working (the "first 80%") within the day. At least if you pick something higher level than C to write it in.

There are many areas to improve upon in DNS, but data model complexity is pretty much bottom of the list. I'd have agreed with your second to last paragraph if it was better targeted than against DNS.