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'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.
Ok so like… think about telcos vs say, whatsapp. WhatsApp is sip, it uses srtp, the whole 9 yards. It works way better than telcos… BUT!!! It rides over telco rails.
This is the dirty truth. What we think of as telco is evolving. Telco is desperately trying not to be a “dumb pipe”, but that’s exactly what the internet wants the base layer to be. When the base layer is opinionated, bad things happen, like net neutrality.
What we want is unbiased fast networks that route data indiscriminately as long as it is correctly formatted and sent from a known address. That’s it.
But telcos can still run voice traffic over “sane” protocols (VoLTE and VoWIFI, for example, are both wrappers over SIP if I'm not mistaken – pretty complex, but still using modern tech). They don't have to be “dumb pipes”, but I don't think there's any need to claw into complicated legacy stuff any more than it is needed to interact with legacy systems.
> VoLTE and VoWIFI, for example, are both wrappers over SIP if I'm not mistaken
Not wrappers. VoLTE is literally SIP with extensions. And VoWiFi is literally VoLTE over IPSec/IKE with EAP auth, so SIP over IPSec. Really just bog standard stuffs.
> – pretty complex, but still using modern tech
Not sure about "modern", but yeah pretty much every actor uses SIP one way or another. It does have a few old stuff (one SIP extension of VoLTE is to allow SIP-negotiated IPSec tunnel. For HMAC it supports md5-96 and sha1-96 and that's all.), but nothing that makes you scream of over-complication.
Yeah VoLTE and VoWiFi were just getting rolled out when I left telecom. It was all IMS and hacks on top of SS7 and stuff like that.
WhatsApp really applied a ton of pressure to telcos and changed the game. Do you remember they an international sms in the US was $.60 per message before whatsapp?
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.
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 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."
> 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!
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 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.
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.
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.
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:
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.
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
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.
> Project Athena was a joint project of MIT, Digital Equipment Corporation, and IBM to produce a campus-wide distributed computing environment for educational use.
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.
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)
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.
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. ;)
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.