Weird DNS entry

I'm learning more about DNS systems and right now I'm studying a very nice project written in Go and I noticed in the code that it queries for some DNS records towards nowhere/?name=probe-test.dns.nextdns.io

Initially I thought that this can't be right, it looks more like an invalid url rather than a domain name but I fired up a console and hit dig nowhere/?name=probe-test.dns.nextdns.io and it returned an A record.

$ dig nowhere/?name=probe-test.dns.nextdns.io

; <<>> DiG 9.11.3-1ubuntu1.11-Ubuntu <<>> nowhere/?name=probe-test.dns.nextdns.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53429
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;nowhere/?name=probe-test.dns.nextdns.io. IN A

;; ANSWER SECTION:
nowhere/?name=probe-test.dns.nextdns.io. 300 IN A 45.90.28.0

;; Query time: 26 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Mar 12 18:55:41 EET 2020
;; MSG SIZE  rcvd: 84

Can someone explain to me how is this a valid entry.


Solution 1:

It's a wildcard DNS entry. The dns.nextdns.io zone is configured to return 45.90.28.0 as a response to a query for anything in front of dns.nextdns.io. Here are some examples, looking for foo and bar. And for good measure, they might already have those two in their zone because they are commonly used for testing and demos, so let's look for something that they won't have anticipated -- NoWayThisExists.

C:\Users\me>nslookup foo.dns.nextdns.io 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    foo.dns.nextdns.io
Address:  45.90.28.0


C:\Users\me>nslookup bar.dns.nextdns.io 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    bar.dns.nextdns.io
Address:  45.90.28.0


C:\Users\me>nslookup NoWayThisExists.dns.nextdns.io 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    NoWayThisExists.dns.nextdns.io
Address:  45.90.28.0

So as long as the stuff you put at the beginning doesn't have any invalid characters that would trip up the DNS resolver, you'll get 45.90.28.0 as a response. And in your case, none of the characters in nowhere/?name=probe-test cause a problem. In fact, you can look up a name consisting of nothing but the symbols /, ?, =, and -.

C:\Users\me>nslookup ///???===---.dns.nextdns.io 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Non-authoritative answer:
Name:    ///???===---.dns.nextdns.io
Address:  45.90.28.0

Solution 2:

The supposed domain name in the question indeed looked unusual, so I went searching for context.

Google led me here https://github.com/nextdns/nextdns/blob/91b3c6cc735c779c730c3b93a7b0372c9e11774f/resolver/endpoint/manager.go#L139 which looks like a perfect match for the string in the question.

Relevant fragments of code:

var TestDomain = "probe-test.dns.nextdns.io"

...

req, _ := http.NewRequest("GET", "https://nowhere/?name="+TestDomain, nil)

If this is indeed it, and it looks like way too good a match to be pure coincidence, it looks like the code in question does not actually make the DNS query claimed in your question, it rather makes an HTTP request based on a URL where nowhere is the hostname part (the part of the URL that would be resolved as part of such a request), path /, and a query string parameter name with the value probe-test.dns.nextdns.io.

As for there being a response when you anyway tried the command dig nowhere/?name=probe-test.dns.nextdns.io as in the question, poking around just a little suggests that there is a wildcard entry *.dns.nextdns.io, so whatever strange names you make up that end with .dns.nextdns.io will result in that same response.
Try eg dig foobar.dns.nextdns.io, which yields the exact same response.

It is worth noting that a name like nowhere/?name=probe-test.dns.nextdns.io is supported by the DNS protocol itself. It is however unclear why anyone would explicitly have wanted to add a name like that (which turned out not to be the case).
(That name is clearly not a valid hostname and it also doesn't match any of the widely used non-hostname use-cases.)