| This tool is so neat! One thing I've learned from it is my ISP (sonic.net) seems to be doing queries to _.example.com. For instance: $ dig @50.0.1.1 nelson.lily6.messwithdns.com a Results in two queries being answered by the messwithdns server. One for nelson.lily6.messwithdns.com as expected, but also one for _.lily6.messwithdns.com. Any guesses what that naked underscore query is for? Not every nameserver does it (Cloudflare, Google, Quad9, and Adguard all don't). But Sonic isn't the only one that does. I've asked on Twitter and the best guess right now is it has something to do with RFC2782 or RFC 8552. But those are about using _ to make unique tokens that aren't likely domain names, things like _tcp or _udp. What would a naked _ mean? |
I wrote the draft algorithm that appears in appendix A of the first experimental RFC describing qname minimization https://datatracker.ietf.org/doc/html/rfc7816#appendix-A
I wrote it because I wanted more specific advice about how qname minimization should work, and I deliberately aimed it at an ideal world, ignoring obvious interoperability problems. I hoped that this would provoke discussion and get people working towards a more realistic algorithm. But that did not happen until years later.
So the early implementations of qname minimization had to invent their own ways of working around the inevitable interop problems, and some of those solutions were quite creative.
I think the bare _ version is trying to avoid querying delegation points directly, so that it still gets a referral as it would have done using the full qname. And the _ also avoids problems with negative responses, which are often implemented very badly - it is common to make a mess of the distinction between NXDOMAIN and NODATA.