Comment by strenholme | Hacker News Reader

Comment by strenholme | Hacker News Reader

Parent Full thread

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 be nice if there was a “.example” TLD;

I don't understand what you want here. RFC 2606 reserves .example for the purpose of examples. I use it all the time for this purpose.

If you want to really register names under that TLD now it isn't an example any more and ceases to serve its purpose.

> While .foo is a real top level domain, Google doesn’t let the public register names in it.

For the record, example.com, example.net and example.org are reserved domains, that cannot be used. So you can always use those as safe examples. https://en.wikipedia.org/wiki/Example.com https://tools.ietf.org/html/rfc2606

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...

> Should we use this CNAME record?

I think you mean “Should we use this A record?”?

> calling them dotted decimal IPs.

Thankfully, with IPv6 we don’t have to worry about it, since the syntax for IPv6 addresses are invalid as domain names.

Thank you for pointing out the typo; I have corrected the grandparent.

It was dnscache.

* http://jdebp.uk./Softwares/djbwares/guide/commands/dnscache....

* http://cr.yp.to/djbdns/dnscache.html

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.

* https://cr.yp.to/djbdns/dns.html

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.

> Oh, DNS is full of these kinds of “not in a RFC but needed to resolve names” corner cases.

What? It's in RFC 1035, and that's noted in the article. There is lots of corner cases in the DNS. This is not one.

Reply on news.ycombinator.com