I could instantly tell this was going to be good when I saw the blog layout. Somehow people who end up going super low level and writing about it have the most unexpected layouts too
There are even more oddities buried in some RRTypes. For example, the 'protocol' field in the DNSKEY RRType. Back when DNSSEC was still in development, the concept of sub-typing was in vogue and it was thought that RRType codes should be jealously guarded. Fast forward a couple of years and everyone realizes that there are plenty of RRType codes to go around and no one really wants to use DNSKEY for other public keys, so the 'protocol' field was basically frozen with '3' being the only value used.
A 35 year old protocol has a lot of vestigial bits, but still vital to network operations.
DNSSEC has been in development since ~1995, and DNSKEY is an early-2000s thing, so a funny thing to look into is why it's DNSKEY and not KEY (this is the infamous "type code roll"), as it was originally.
Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community.
I kind of think this is a dig bug -- the man page indicates you can specify `name type class queryopt` in an unargumented style, but when using IN in this fashion against `ch` it does not work correctly (testing on Debian 11 stable). Compare these 4 sets of results:
dig ch NS IN +short
dig -q ch -t NS -c IN +short
dig uk NS IN +short
dig -q uk -t NS -c IN +short
Only when using the first form do you get a comment ";; Warning, extra class option" and the incorrect results. So even when using the full pattern of un-argumented options as outlined in the man page, it fails to work as expected specifically for ch.
Except upvoted comments continue to propagate confusion over what's actually happening by omitting the root zone from example hostname queries.
While this is a fully qualified domain name:
www.example.com
This is the actual domain name:
www.example.com.
The linked article and doesn't really explain why someone should add the trailing dot to the hostname. I do: It's the name of the root DNS zone and unambiguously identifies the `dig` parameter as a hostname.
And to avoid ambiguity, you can just include the root zone in all URLs you’re using as well (unless the server you’re talking to doesn’t implement the DNS RFCs correctly, which sadly is getting more and more common in recent years)
no. I tried using Ethernet to transport Chaosnet between emulators. Didn't work as I hoped it would, although I forgot the exact issues that I encountered.
side note: Not thicknet, but I do have thinnet still running here although that only carries IPX/SPX and some TCP/IP :-D
>I tried using Ethernet to transport Chaosnet between emulators.
Hey, what ever you’ve got at layer 1 (thick eyes, thinner, 10baseT) the next layer up is Ethernet!
> I do have thinnet…
There must have been chaosnet over thinnet that I just don’t remember.
But since you have thinnet you should drop some pups on there so your Altos can talk to each other. Get your mail via Grapevine (still superior to IMAP)… have some fun!
The CH class record stores the chaosnet host id that corresponds to the dns entry. Chaosnet didn't use IP addresses (which are specific to the internet protocol) to identify hosts - it used a 16 bit number composed of an 8 bit subnet ID and a 8 bit subnet-local host ID.
When querying the DNS you specify the class of address you want (IN, CH, whatever) and the resolver returns you the corresponding record. So if a host has a connection to an IP network and an Chaosnet network then it would have two entwork identities and its DNS zone would contain both classes of ID.
Obviously IN is really the only network class that is used now, but these things persist in old code.
/root is a directory called "root" based in the root directory
Did you get that?
Simples, now you see, dns is the same thing backwards with dots...
All that before user gets to type "www.google.com."
Interestingly, in China people just type a single word and the default search engine does the thinking. Giving them power that google.com can only dream of. ;)
The DNS "master file"/"zone file" format is a bloody disaster for the same reason, and practically unparseable. Every implementation parses them differently when it comes to parenthesis.
From the grammar in RFC 1035:
<domain-name><rr> [<comment>]
<blank><rr> [<comment>]
<rr> contents take one of the following forms:
[<TTL>] [<class>] <type> <RDATA>
[<class>] [<TTL>] <type> <RDATA>
All the columns being optional creates the ambiguity between the <class> and <domain-name> columns in the TTL missing/2nd form. In the real world <class> is always "IN". It's even worse since the set of <type>'s is unbounded and the <RDATA> grammar depends on <type>
Bind's config files are awful. I think it is like Sendmail where the only reason it is still awful is that there is too much infrastructure built around them to make them better. They could improve the configs, but it might break many thousands of scripts around the world.
Back in the 80s there were not many examples of configuration files, so everybody just invented their own idiosyncratic format. Most of those old formats have long since died off, but a few have survived to haunt us even today.
sendmail.cf is bytecode. At the time it was written, bytes mattered, and it did a magnificent job. Now we have the resources to make things easier on humans.
but there really should be some sort of charity foundation to help the victims of sendmail.cf trauma.
Yeah, though I would say human readable bytecode, and it is interesting to see that in the actual context. For anyone who's interested, there's a git repository containing a historical reconstruction of the original BSDs.
From what I grasp, it started as an extensive dynamic parser that needed to understand a lot of rules, and I guess with each new RFC and version, the rules needed to be extended too. And the config file could be loaded into a memory image to improve performance.
I've been running BIND since 1995. Most configurations are very similar. A zone is either primary / master or secondary / slave. You copy and paste from a previous config entry, change a zone name, maybe add an extra secondary name server now and then.
Also, the zone file format is defined by an RFC. Which is why several a lot if DNS software uses that format, not just bind. Bind in particular, is conservative about deviating from the standardized format.
BIND's zone files are an implementation detail completely unnecessary to interoperate with the DNS protocol. Same for zone-transfers. Neither of these ever belonged in an RFC in the first place.
When I worked with MS Windows DNS server a few years ago, I was surprised to see that it stored domain information in (temporary?) files with a format very similar to that of BIND zone files (I can’t remember if the Windows server was primary or secondary for that domain).
Regarding zone transfers, I think it makes sense that the AXFR and IXFR protocols are specified in RFCs. Neither the server nor client should care about what software is used by the other host to implement the agreed protocols.
So I did used to use the axfrs back when I used to use bind. It’s clear text. It requires updating a serial number for no other reason than for the client to know to update. It’s based on polling. It exposes more complexity in the server that isn’t needed. It’s an archaic and dumb protocol.
There’s nothing wrong with it in the same way there was nothing wrong with telnet or ftp.
I’m actually aware of that. Hacks upon hacks. And it doesn’t address the other issues.
I’m glad axfr works for you and you’re happy with it. I stopped using bind after a multitude of security issues it had over the years and I haven’t looked back. When I did used to use it, I switched to rsync for zone files probably sometime around 2000.
All of this is completely besides my original point: the zone file format needn’t have been an RFC, and probably not AXFR either. As far as I’m aware, no other RFC specifies implementation-specific decisions like the DNS RFCs do. It would be as if the sendmail.cf format had an RFC. AXFR is idiosyncratic and as recently as a decade ago underspecified:
I don’t know why the author laughed about Hesiod,* which, like chaosnet was another MIT protocol in use for a while.
There was a time when these records were handy — I was pretty excited when I could connect directly from my desktop machine at PARC to a host at the AI lab on the MIT chaosnet. Before the ARPANET transitioned to TCP I had to manually hop through a couple of protocol gateways to make connections like these. Afterwards it was transparent.
BTW CHAOS used strings to identify ports/protocols rather than reserved numbers. So there is a lot you can store in a compliant implementation of the DNS.
* Also the bane of some high school classes, but that’s quite another matter.
> I don’t know why the author laughed about Hesiod,* which, like chaosnet was another MIT protocol in use for a while.
Probably because you are maybe one of a few hundreds of people who have made use of this (and it was decades ago), out of the billions of people who have used the internet.
Well, I guess if you used Hesiod with DNSSEC. But that’s like saying you could use NIS with secure RPC, possible in theory but no one would build such an implementation because the world moved on.
Weirdly I did actually implement a Hesiod plugin for macOS once, it never shipped though.
All this does to me is show that the author didn't really research and just brushed it off. It is quite the trend. "I'm not aware of it, so it must not be important" type of thing.
Nah, I think it is more of a "here's this other thing that never caught on, and you probably don't know about that will live on forever because it is part of DNS."
Great article, I did know about this at all... DNS is super interesting. I wrote dug, a cli tool I made to help visualize DNS 'propagation' but is a great learning tool. Similar to dig and dog, but specifically for querying or watching large numbers of DNS servers at once.
117 comments
[ 13.9 ms ] story [ 2900 ms ] threadhttps://hackers.town/@seachaint/108645588430551049
https://matrix.org/bridges/
I then use the WordPress WebMention plugin - https://github.com/pfefferle/wordpress-webmention - to render them nicely.
Seems similar to the problem on YAML's Norway (https://hitchdev.com/strictyaml/why/implicit-typing-removed/) and the Turkish Lira (TRY) problem (https://devblogs.microsoft.com/oldnewthing/20190912-00/?p=10...)
I recall (All) DNS Resource Records listed [1], which is another treasure of historical tidbits.
[1] https://www.netmeister.org/blog/dns-rrs.html
A 35 year old protocol has a lot of vestigial bits, but still vital to network operations.
Hobbyist Chaos network: http://chaosnet.net/
https://news.ycombinator.com/newsguidelines.html
While this is a fully qualified domain name:
This is the actual domain name: The linked article and doesn't really explain why someone should add the trailing dot to the hostname. I do: It's the name of the root DNS zone and unambiguously identifies the `dig` parameter as a hostname.https://wiki.dfupdate.se/projekt:mini-conference
side note: Not thicknet, but I do have thinnet still running here although that only carries IPX/SPX and some TCP/IP :-D
Hey, what ever you’ve got at layer 1 (thick eyes, thinner, 10baseT) the next layer up is Ethernet!
> I do have thinnet…
There must have been chaosnet over thinnet that I just don’t remember.
But since you have thinnet you should drop some pups on there so your Altos can talk to each other. Get your mail via Grapevine (still superior to IMAP)… have some fun!
Long story short:
Someone entered some characters erroneously in the Unicode spec and now those characters are there FOREVER.
The fact that no-one necessarily knows how to read them aloud (some of them you can guess, some of them are very unclear) can be a fun wrinkle.
When querying the DNS you specify the class of address you want (IN, CH, whatever) and the resolver returns you the corresponding record. So if a host has a connection to an IP network and an Chaosnet network then it would have two entwork identities and its DNS zone would contain both classes of ID.
Obviously IN is really the only network class that is used now, but these things persist in old code.
[1] https://linux.die.net/man/1/nslookup
/bin is a directory called bin
/ is the root directory
/root is a directory called "root" based in the root directory
Did you get that?
Simples, now you see, dns is the same thing backwards with dots...
All that before user gets to type "www.google.com."
Interestingly, in China people just type a single word and the default search engine does the thinking. Giving them power that google.com can only dream of. ;)
From the grammar in RFC 1035:
All the columns being optional creates the ambiguity between the <class> and <domain-name> columns in the TTL missing/2nd form. In the real world <class> is always "IN". It's even worse since the set of <type>'s is unbounded and the <RDATA> grammar depends on <type>I believe this is one reason why tinydns has its own format https://cr.yp.to/djbdns/tinydns-data.html
Back in the 80s there were not many examples of configuration files, so everybody just invented their own idiosyncratic format. Most of those old formats have long since died off, but a few have survived to haunt us even today.
but there really should be some sort of charity foundation to help the victims of sendmail.cf trauma.
I believe one of the first BSD versions containing sendmail (by Eric Allman) is this one: https://github.com/weiss/original-bsd/blob/bd282c88c1b3c2575... (almost 40 years ago!)
Its a little hard to read due to the format, but here's some explanation of the (1983, earliest?) config file that was used back then: https://github.com/weiss/original-bsd/blob/bd282c88c1b3c2575...
From what I grasp, it started as an extensive dynamic parser that needed to understand a lot of rules, and I guess with each new RFC and version, the rules needed to be extended too. And the config file could be loaded into a memory image to improve performance.
You may have to rtfm, but only once.
https://github.com/PowerDNS/pdns/blob/master/pdns/zoneparser...
And in BIND where the <rdata> parsing is coded up for a bunch of <type>'s:
https://github.com/isc-projects/bind9/tree/main/lib/dns/rdat...
Regarding zone transfers, I think it makes sense that the AXFR and IXFR protocols are specified in RFCs. Neither the server nor client should care about what software is used by the other host to implement the agreed protocols.
There’s nothing wrong with it in the same way there was nothing wrong with telnet or ftp.
https://cr.yp.to/djbdns/axfr-notes.html
That feature was added well over a decade ago. Your changes on the primary will be replicated (within seconds) to your secondaries.
I’m glad axfr works for you and you’re happy with it. I stopped using bind after a multitude of security issues it had over the years and I haven’t looked back. When I did used to use it, I switched to rsync for zone files probably sometime around 2000.
All of this is completely besides my original point: the zone file format needn’t have been an RFC, and probably not AXFR either. As far as I’m aware, no other RFC specifies implementation-specific decisions like the DNS RFCs do. It would be as if the sendmail.cf format had an RFC. AXFR is idiosyncratic and as recently as a decade ago underspecified:
https://datatracker.ietf.org/doc/html/rfc5936
And it looks like there’s still ongoing work to make it secure:
https://www.rfc-editor.org/rfc/rfc9103.html
There was a time when these records were handy — I was pretty excited when I could connect directly from my desktop machine at PARC to a host at the AI lab on the MIT chaosnet. Before the ARPANET transitioned to TCP I had to manually hop through a couple of protocol gateways to make connections like these. Afterwards it was transparent.
BTW CHAOS used strings to identify ports/protocols rather than reserved numbers. So there is a lot you can store in a compliant implementation of the DNS.
* Also the bane of some high school classes, but that’s quite another matter.
Probably because you are maybe one of a few hundreds of people who have made use of this (and it was decades ago), out of the billions of people who have used the internet.
Cool story though.
Weirdly I did actually implement a Hesiod plugin for macOS once, it never shipped though.
Every time I see the headline, that's how I first read it.
I wonder if I'll ever grow up.
dig Esoterica*
https://github.com/unfrl/dug
https://dug.unfrl.com