I guess the point is that "the common foo.bar.com DNS notation" is not really "DNS notation" at all but a common domain name notation used in the operating system/application layers regardless of resolution mechanism.
In fact, it's clearly a different notation from the one that the DNS protocol uses, so there being a difference in capability there is not hugely surprising.
For the actual DNS protocol it's not actually that shocking, there dots have no special meaning and the same applies to any other byte value.
Instead, of the dot-separation the DNS protocol prefixes each label by an integer specifying the length.
However, there being a difference between the capabilities of how domain names are handled by the OS/application and by DNS and possibly other resolution mechanisms in use clearly creates an opportunity for confusion/inconsistency/disaster/... when mapping between the native format of each resolution mechanism (the 8bit clean "DNS wire notation" in the case of DNS) and the "string representation with dot-separation".
I suppose the idea is that the resolver library in the operating system ought to take care of this mapping (escaping or discarding or whatever should be done for names that can not be represented in the dot-separated string notation) once and for all and let the applications just do their thing.
Posted Nov 16, 2012 23:54 UTC (Fri) by Comet (subscriber, #11646)
[Link]
The bind library does.
That doesn't stop people writing code like:
labels = result.split('.')
shorthost = labels[0]
If you split on '.', then you break when presented with the escaped form '\.' as you'll do an extra split. You might get away with it when only looking for the TLD, or just sorting data and rejoining the strings.
So, there's an escaping mechanism, it helps a lot of the time, but other times it produces surprising results and you need to at least know that the escaping mechanism is in use.