Oh, DNS is full of these kinds of “not in a RFC but needed to resolve names” corner cases. I will show just one:
(While .foo is a real top level domain, Google doesn’t let the public register names in it. It would be nice if there was a “.example” TLD; “.invalid” looks wrong and using “example.(com|org|net)” is awkward when using multiple domains in an example. 10.X.X.X should not be resolved at the internet-wide DNS level in the real world, but these are examples, not real-world cases)
We get this packet when asking the domain1.foo nameserver for blog.domain1.foo
blog.domain1.foo CNAME blog.domain2.foo
blog.domain2.foo A 10.1.2.3
Should we use this A record? BIND, about 20 years ago, did use this A record. DJB rightfully screamed bloody murder (since BIND allowed domain1.foo to alter the cache for domain2.foo), and would not accept the IP. MaraDNS (Deadwood, these days), on the other hand, accepts the IP, but stores it in the domain1.foo record (so domain1.foo does not affect cache entries for domain2.foo).
Now, the correct thing to do is to not accept the domain2.foo record at all unless it comes from a server in domain2.foo’s bailiwick, since that is how modern versions of BIND do it. Otherwise, there are a small number of poorly configured corner cases (where domain1.foo has an outdated IP for domain2.foo) which will resolve incorrectly.
Now, back to the article, I believe DJB had a way of handling this: If it saw “domain2.foo MX 10.2.3.4”, it would then, if asked for the IP for the domain “10.2.3.4”, return the A record (IP) 10.2.3.4 (or was it Qmail which did the expected thing if it saw a dotted decimal domain name? Or both? There are enough old school DJB advocates here that someone should be able to clarify)
I know this much: DJB made some noise two decades ago that this is a real-world misconfiguration which should be accounted for and handled the expected way, calling them dotted decimal IPs.
It would have been nice if "cannot be used" meant that no one would be allowed to register it. From what I can see, example.org very much resolves and accepts HTTP connections. It even has an MX record...
And it wasn't to do with bailiwick at all. It was to do with the fact that many softwares allowed users to enter either IP addresses or domain names; but either left recognizing IP addresses up to the DNS client libraries, some of which would in turn fail to do so and just treat them as domain names, or recognized IP addresses in a form that users would forget to use, such as having them enclosed in square brackets. M. Berstein's own DNS client library, and several others, do the same thing that dnscache did, in the client library itself, implementing this same defence at multiple layers of the system.
A related scenario: Some Unix/Linux softwares allow one to specify users by either ID or name, but fail to take advantage of the fact that the colon is prohibited in account names, and so can be used as a syntax for unequivocally distinguishing between the twain. As a result, strings like "0" can potentially be mapped to something other than the superuser if someone goes and creates a user account with the name "0" (whereas ":0", as in the syntax for some tools, is unequivocally user ID zero and "0" generates an error unless there is actually an account by that name). This in turn leads to people arbitrarily banning account names with digits, and security holes resulting when the action upon encountering attempts to use such a name is to just ignore them. Recall the "User=0pointer" kerfuffle in systemd.
(While .foo is a real top level domain, Google doesn’t let the public register names in it. It would be nice if there was a “.example” TLD; “.invalid” looks wrong and using “example.(com|org|net)” is awkward when using multiple domains in an example. 10.X.X.X should not be resolved at the internet-wide DNS level in the real world, but these are examples, not real-world cases)
We get this packet when asking the domain1.foo nameserver for blog.domain1.foo
Should we use this A record? BIND, about 20 years ago, did use this A record. DJB rightfully screamed bloody murder (since BIND allowed domain1.foo to alter the cache for domain2.foo), and would not accept the IP. MaraDNS (Deadwood, these days), on the other hand, accepts the IP, but stores it in the domain1.foo record (so domain1.foo does not affect cache entries for domain2.foo).Now, the correct thing to do is to not accept the domain2.foo record at all unless it comes from a server in domain2.foo’s bailiwick, since that is how modern versions of BIND do it. Otherwise, there are a small number of poorly configured corner cases (where domain1.foo has an outdated IP for domain2.foo) which will resolve incorrectly.
Now, back to the article, I believe DJB had a way of handling this: If it saw “domain2.foo MX 10.2.3.4”, it would then, if asked for the IP for the domain “10.2.3.4”, return the A record (IP) 10.2.3.4 (or was it Qmail which did the expected thing if it saw a dotted decimal domain name? Or both? There are enough old school DJB advocates here that someone should be able to clarify)
I know this much: DJB made some noise two decades ago that this is a real-world misconfiguration which should be accounted for and handled the expected way, calling them dotted decimal IPs.