A technical blog post explaining a DNS protocol quirk affecting Switzerland's country code (.ch interpreted as Chaosnet rather than country code). The content contributes to technical education and internet culture documentation through accessible explanation of complex systems. Structurally, the blog demonstrates openness through free access, active commenting, and social sharing, supporting rights to education, freedom of expression, and participation in scientific and cultural life.
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>
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.
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.
> The IN and CH class names overlap with the IN and CH top level domain names. Either use the -t and -c options to specify the type and class, use the -q the specify the domain name, or use "IN." and "CH." when looking up these top level domains.
Off-topic: I got excited when I saw the nicely coloured output from dig which makes it more readable. I thought that maybe the author has some new version that’s not yet available on Ubuntu LTS. Unfortunately, the nice colours are from judicious use of highlight.js¹ – one good reason to have uMatrix configured to allow first-party JavaScript!
> Project Athena was a joint project of MIT, Digital Equipment Corporation, and IBM to produce a campus-wide distributed computing environment for educational use.
Man, not putting Fully Qualified Domain Names in code has been such a recurring source of pain in my software life. You make so many assumptions about the way people parse domain names and all of them are wrong. Vendors do all kinds of things to "simplify" their workflows internally and sometimes they just parse URLs and domains in all kinds of ways that break your brain.
Reminds me so much of the way "smart" telecom engineers bastardized SS7 to ship new features onto legacy telco infrastructure. SS7 is like 20M lines of C. You can't really change it without breaking it in many other places, AT&T used to have a metric which was something like "for every 10 lines of code you alter in SS7, you create 8 bugs in other parts of the code." So "smart" telecom engineers would take existing fields in the SS7 logic and use them for different functions inside of their telco. A billing field could instead be used as a feature flag for some sort of customer state, but only inside of the telco's network (and re-written back to the compliant SS7 standard when the data was headed out of the network). This was called encapsulation and wrapping and un-wrapping packets just in time was the source of many many problems in my telecom life.
Just in time editing of network packets at the boundary is always fun. Most of the problems that would happen would come from forgetting to rewrite back to SS7 and transmitting the internal codes out.
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
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.
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.
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.
> 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.
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.
yeah .com and many others. You just need to think of some research reason which can be a lot of things, there's no real verification on this, and then you get access to all of the domains at once (you need to be accepted into this central zone dump system once). I was quite surprised when a colleague told me this exists and that he was accepted, since to me this seemed to be coveted data by e.g. commercial dns history companies. Anyhow, if you didn't already --for the myriad of other reasons-- consider DNS data to be open, you should consider it open data.
I'm wondering why telcos don't use SIP (and something with sane APIs for the data / control plane) or something internally? Maybe for peering with other networks, too.
build aba2bc8+myve · deployed 2026-02-28 16:36 UTC · evaluated 2026-02-28 16:29:11 UTC
Support HN HRCB
Each evaluation uses real API credits. HN HRCB runs on donations — no ads, no paywalls.
If you find it useful, please consider helping keep it running.