After reading https://github.com/nudgepad/space/issues/54#issuecomment-212... , I don't see how your method is superior to the existing BIND zonefile syntax. It requires one to keep significantly more state in one's head while editing the file and (because the meaning of the data in the file depends on where it is in the file) makes drive-by one-off editing much harder. (Being able to "echo '@ 60 IN A 1.1.1.1' >> my.zonefile.zone" is pretty convenient.)
Thanks for the comment. I'm sure there's a much better DSL than the one I proposed, perhaps that takes into account the ability to append to the file.
My theorem though, is that there exists a Space DSL that is 10--100x better than the current BIND syntax. In other words, you can accomplish everything that BIND does, using a syntax that is general/universal. The latter part is what gives you the 10x-100x improvement over BIND. Learning BIND provides you almost no benefit in other domains, and worse, mastering other languages is irrelevant when you encounter BIND. Why am I so confident in this? We've been applying Space in all sorts of domains, and time and again it comes up that it works in any domain, better than the existing specific languages.
The benefit if you know how to use Space--and knowing Space takes less than 20 minutes to master it for a programmer since there are 3 rules, 2 syntax characters (space and newline), and it is impossible to have a syntax error--you then can easily read and write code that works across all sorts of domains--HTML, CSS, Makefiles, BIND, HTTP---et cetera.
I'm a seasoned programmer (15,000 hours experience), and looking at BIND makes me groan.
Now, the DSL I whipped up I'm sure is not the DSL that could replace BIND--I took less than 7 minutes to come up with that one and my knowledge of BIND/DNS is only partially--but I'm highly confident that it is relatively close and with a few tweaks you could create a DSL that is better than the status quo. Which is pretty amazing because this is so level that your work would improve the Internet and DNS in a significant way.
Sorry, to me this is absolutely nonsense. Your keywords is also syntax. That there are only two "syntax characters" is not an advantage - it forces you to make the grammar for your DSL's vastly more verbose by using keywords for all kinds of situations that could otherwise easily be expressed with syntax. As a (programming) language geek that cares deeply about syntax and writes compilers for fun, the very idea is abhorrent to me. It sounds like COBOL for the new millennium.
And that you "groan" from looking at BIND zone files tells me that you don't understand the underlying data model, rather than that the zone files are complicated - they map very well to the data model, and there are very few caveats with the format. (The one big one that tends to trip people up is the full stop vs. no full stop at end of host names).
Further, I think you still are confused about the importance of zone files here: If you don't like them, don't use them. Use software that gives you a nice fussy interface instead. Zone files are only still important because people still pick software that uses zones files.
A new format here would change pretty much nothing: Those who run bind will not change software because of a file format change; people run Bind because it has a track record, and is well understood. People switch from Bind because they have different needs. Many of those who pick something else pick DNS servers that don't even store records in files, or in other formats, so a replacement for the zone file format is irrelevant to them.
> Further, I think you still are confused about the importance of zone files here:
You are right. To be honest I don't know off the top of my head how many protocols/encodings are currently used to make DNS work.
I know I have an /etc/hosts file on my machine. I know there are zone files on DNS servers. In the past I've downloaded those massive files from places like Verisign et cetera that contain all the records. I know dig does some stuff.
My point is all that is unnecessary.
The whole thing could be made much simpler, if done in an object oriented way using Space as the encoding.
Say I wanted to go to google.com.
My browser could check the local domains.space file to see if there's a google.com match. If not, it could then send a space message to my ISP's (or other) DNS server:
question google.com
And get a response:
question google.com
answer 123.123.123.123
My point is you could apply this clean, simple, object oriented, punctuationless system across the entire DNS stack.
First, what makes you think your 'Space' format has "no syntax" ? What do you think keywords and whitespace are? You've just replaced 'A' with 'ip', and presumably 'CNAME' with 'address' (which is actually much less descriptive). You've also added a keyword to specify the TTL of individual records, rather than an optional positional parameter.
More importantly, semantics are always more involved than syntax. By the time you understand how DNS works (which will take one basically an afternoon of playing), the few idiosyncrasies of zone file syntax are trivial. Each line is pretty much a textual description of the records that are sent over the wire, with a little punctuation and directives to set defaults for the file.
PS if you're looking to do anything programmatic, install PowerDNS instead - it can use a database for your zone info.
Right, there is a syntax. No punctuation, is what I should say.
Again, the DSL I gave is not optimal. It would take a few iterations.
My argument is that the few idiosyncrasies of zone file syntax are not trivial. Road signs are trivial. Hundreds of millions of people can see a sign and get it right away. My argument is that DNS could be trivial, and my prediction is a Space based DSL will emerge that makes it so.
Like, why would I use this? Yes, it takes an hour or so to understand simple DNS and it can certainly take weeks or even years to really understand complex DNS...but it's not the zone file format that makes this hard, it's that DNS is hard.
"More efficient" doesn't make me care because it's already efficient enough that the bottleneck in DNS is elsewhere. Being more useful, doing things I can't already do, makes me care. So why should I care?
DNS creates an alias from a name to the implementation.
This is really powerful for a set of reasons.
One, humans think with a combinatorially larger language than numbers, so having to work with addresses like 723.123.322.123 would be painfully slow. "Apple.com" is much easier.
Two, you can refactor the implementation without changing the interface. Ie, you can build a whole new Apple server, but just change the alias, and not have to teach the whole world to now go to Apple2.com.
It's pretty neat. The whole thing should be pretty simple. However, it's not. If it were simple, you would see a lot of programmers interacting with DNS on a more meaningful level (than just buying domains and changing A records and CNAME records according to steps they Googled and not according to an understanding of how DNS works).
Each DNS record could just be an object encoded in Space. Doing so would allow you to start innovating at a core part of the Internet, instead of on a tower of cryptic stacks.
IE:
record
domain apple.com
ip4 723.123.322.123
ip6 21:21:213:213:::213
expires 2/23/2013
createdBy Tim Cook
mirrors
1 723.123.322.322
2 123.123.322.322
Setting your condescension aside, I am a programmer, and I do interact with DNS on a more meaningful level. It's not the interface: it's the concepts that are hard.
Frankly, I don't understand what's so complicated about
HOST TTL [CLASS] TYPE RDATA
Even the SOA record's RDATA is pretty simple:
AUTHORITATIVE_NAMESERVER ADMIN_EMAIL_ADDR (SERIAL_NUMBER REFRESH_INTERVAL UPDATE_RETRY_INTERVAL EXPIRE_INTERVAL NXDOMAIN_CACHE_INTERVAL)
Let's define a simple empirical test to compare "X" to "Y" in terms of complexity:
How long would it take for a person to write code that reads and writes code in format "X"?
How long would it take for a person to write code that reads and writes code in format "Y"?
Let's call the current status quo of Bind/Zone "X".
My prediction, is there exists a Space based DSL that is functionally equivalent to X, let's call it "Y", that measures an order of magnitude better than X in terms of the complexity measure I defined above.
And why is this important? If it were a lot easier to write code that reads and writes code that operates at one of the lowest levels of the Internet, it would unleash a wave of innovation that is hard to predict the magnitude of.
I'm certainly not one to dismiss someone's hobby project; if it's a thing that is fun to work on, more power to you. You might even get a really useful result out of tinkering with it!
I'm having a hard time imagining anything that's simpler than this p-code parser for a simple BIND-style zone file:
if syntax error is encountered, abort with error
read host
read ttl
optionally read class
read type
load expected rdata format for type
read rdata
if record read was duplicate data, abort with error
Things get slightly more complicated when you add in $KEYWORDS, but not all that much.
Anyway, if you can find a format that's an order-of-magnitude easier to work with than this, my hat's off to you. (If I were the sort of person that regularly found these sorts of things, I'd own an apartment building, rather than renting space in one. ;) )
You don't need to read or write zone files to write DNS servers. Zone files are irrelevant unless you want to be able to import Bind zone files for interoperability.
So why exactly do you think this "operates at one of the lowest levels of the internet"? It does not.
DNS servers do not talk to each other using this format.
Great code example simoncion! Thanks for taking the time to write up that comment.
You're example does indeed show a simple reader of BIND-style zone files.
But, to write that, you brought to the table an understanding of BIND that I'm sure took you a long time to develop.
A good Space DSL does not require a lot of domain knowledge to pick up.
In other words, while the current BIND zone format uses punctation to indicate meaning, which then requires domain knowledge to read/write (or a textbook by your side), a good Space DSL is self documenting. So, my example using things like A and CNAME and TTL would be bad. Better would be something like this:
What is updated every 3600 seconds here? The entire breckyunits.com zone? The "ipv4" record? the ipv6 record? both?
Zone files can express all of those easily, and need to. To be able to replicate their functionality, your DSL would need to be able to handle TTL's for each and every record.
To me, your example is extremely ambiguous. It is certainly not self documenting. Because I happen to know DNS, I'd assume you're assigning a TTL for all the records of 3600.
But how can I set the TTL only for one of them?
And how do I add records for subdomains? Do I have to repeat the full name every time? Because that's a non-starter.
And do you realize you've actually made this massively harder to work on with simple tools? Bind zone files keeps all except the SOA record on one line. This means that with some simple conventions, a site can easily format everything so that a single record can always be manipulated simply by operating on a single line of text. That makes it trivial to e.g. modify zones files in shell scripts with tools like "awk" etc.
Almost anyone that needs to read and write zone files have advanced requirements - or we'd use a more user friendly, high level tool. And so a replacement would need to meet those requirements, including being able to write records on a single line, and being able to refer to the origin and use relative names.
For subdomains, you could do a "/domains/foobar.google.com.space" file, or maybe a "/domains/*.google.com.space" file, or maybe you just put them in the file above like so:
Et cetera. The implementation details would be very important. There are plenty of sub decisions to make to come up with a great DSL. But I'm fundamentally confident that at the root level, the decision to create a Space based, object oriented domain system is not only correct, it is inevitable. It just feels right to me. Again, I've had the benefit of working with this structure for a while now, and am amazed at how so many things simplify down to it. Space is object oriented programming in an extremely simple, concise, robust, human readable way. Just as most (if not all) major computer programs nowadays are written in an object oriented way, I am predicting there will come a time when most major message passing systems are written in a Space encoded way.
> That makes it trivial to e.g. modify zones files in shell scripts with tools like "awk" etc.
I look at awk and I think that's something that will at some point be buried, and should be. awk is kind of like a neanderthal or some other species in between ape and human. Served it's purpose, helped the evolutionary chain, is a very honorable tool, but at some point will go extinct.
It took me an afternoon of reading the docs on Wikipedia and Zytrax to grasp the basics of both zone files and BIND config files, and another hour or three with the tunnelbroker.net "certification" tests to grasp stuff like glue records. That's... not a long time to invest for such a useful thing.
Also, the only punctuation I see in a zone file is for comments, $KEYWORDS, the SOA record, and "@" to indicate that a record is meant to apply the $ORIGIN. Did I miss something?
If you don't like "A", "CNAME", and "TTL", let me propose a preprocessor that lets you do the following:
host1.example.com update-3600-secs ip4 1.1.1.1
host1.example.com update-12-hours ip6 2001::1
host2.example.com update-24-hours alias host1.example.com
host1.example.com update-1-week physical-location 52 22 23.000 N 4 53 32.000 E -2.00m 0.00m 10000m 10m
This format retains the greppability of the existing zone file format as well as its drive-by appendability, while allowing one to ease one's way into the actual zone file syntax that's being used by your DNS server.
