Use of Mixed Case DNS Queries
In my DNS server query logs, I am starting to see more queries using mixed case, like for example:
jOHanNEs.HoMePC.OrG www.HOMEPC.ORg wWW.Homepc.org Www.HoMepC.ORg WwW.homepc.ORg WwW.HOmepc.oRG WWw.homePc.oRg
These queries appear to be the result of DNS servers supporting a relatively new DNS security mechanism, "0x20 Bit encoding". The approach got its name from encoding a bit value using the case of letters. if bit 0x20 is set in a byte, the letter is lower case. If it is cleared, the letter is upper case.
For example, the first value show above ( www.HOMEPC.ORg ) represents a value of 11100000001 . How does this help DNS security? Host names are not case sensitive. However, the case is maintained. The answer will use the same mixed case as the query. For example:
> dig WwW.HoMePc.OrG ; <<>> DiG 9.7.3-P3 <<>> WwW.HoMePc.OrG ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15335 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 4 ;; QUESTION SECTION: ;WwW.HoMePc.OrG. IN A ;; ANSWER SECTION: WwW.HoMePc.OrG. 100 IN A 70.91.145.9 .. [rest of answer omited] ...
As it turns out, almost all DNS servers follow this behaviour. The new part is that now some DNS servers start to deliveratly encode a random value into each query they send, and then verify if the value is maintained in the response. This in effect adds additional bits to the query id.
While this is clearly a "hack", it is a pretty attractive one. If your DNS server supports this feature, it will automatically gain a few more bits of "spoofing resistance". The DNS servers it connects to do not need to change anything. Unlike for DNSSEC, which is of course the real fix, but requires extensive work to configure,and has to be configured for each zone.
Right now, none of the major DNS servers appear to support this feature. A Google search only found two pieces of software that do:
Unbound: https://calomel.org/unbound_dns.html: see "use-caps-for-id"
pydig: http://www.huque.com/software/pydig/
I would be interested to learn if there are other DNS servers (or DNS related software) that supports this method.
References:
http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
http://courses.isi.jhu.edu/netsec/papers/increased_dns_resistance.pdf
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Application Security: Securing Web Apps, APIs, and Microservices | Washington | Dec 13th - Dec 18th 2024 |
Comments
Damian Menscher
Jan 18th 2012
1 decade ago
Example from just a few seconds ago:
08:18:58.615437 IP my.tor.exit.node.1194 > 4.2.2.2.53: 2617+ A? GEOIp.VIdaLIa-ProjEcT.net. (43)
08:18:58.731285 IP 4.2.2.2.53 > my.tor.exit.node.1194: 2617 NXDomain 0/1/0 (111)
08:19:34.467587 IP my.tor.exit.node.1195 > 4.2.2.3.53: 4839+ A? wWw.GOOGle.COm. (32)
08:19:34.528849 IP 4.2.2.3.53 > my.tor.exit.node.1195: 4839 6/0/0 CNAME www.l.GOOGle.COm., A 74.125.224.212, A 74.125.224.208, A 74.125.224.209, A 74.125.224.210, A 74.125.224.211 (132)
n3kt0n
Jan 18th 2012
1 decade ago
It turned out to be a GoDaddy "feature" on their domaincontrol.com servers:
http://unbound.net/pipermail/unbound-users/2011-June/001849.html
It seems to be fixed, as their servers return fixed case and I turned it the flag back on sometime late 2011 and haven't any major issues so far.
steve
Jan 18th 2012
1 decade ago
And this is kind of in violation of the robustness principal.
DNS servers that always replace lowercase, uppercase, or with the record matching the zone, will be detected as "spoofing", even though they are not.
Therefore those domains will be unable to be resolved, even though they are valid domains!
Discarding the DNS response because the case of letters in the response is different would be a RFC violation on the client side.
I will admit that it is a very clever hack. But one that is not at all attractive for implementation on production recursive DNS servers/client resolvers.
Draco
Jan 18th 2012
1 decade ago
Joshua
Jan 18th 2012
1 decade ago
inkling
Jan 19th 2012
1 decade ago
inkling
Apr 8th 2015
9 years ago