18

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.

Improve this question
2
  • 1
    I'm not sure it is! My guess it depends on the rfc they rely on (which I have not tracked down - although apparently this is forbidden in RFC1123 - mailarchive.ietf.org/arch/msg/dnsop/Yi8PvVDKNdS8OEs25QkvxjP0SMM is old but interesting read ). From a fundamental POV a domain name is just a database entry so its probable its simply seen as a character string and served up.
    – davidgo
    Mar 12, 2020 at 18:57
  • 1
    @davidgo The key point there is pretty much "Hostnames and domain names are different things and are NOT interchangable". Hostnames are a subset of domain names following stricter naming rules and required in specific contexts. The DNS protocol itself supports domain names (less strict), but for example an http URL requires a hostname specifically (more strict), so the most commonly seen names in DNS are hostnames.
    – Håkan Lindqvist
    Mar 12, 2020 at 20:49

2 Answers 2

Reset to default
34

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
Improve this answer
4
  • 1
    Solid. Thanks! First time I hear about wildcard DNS.
    – Romeo Mihalcea
    Mar 12, 2020 at 23:26
  • 1
    As far as I remember, the original RFCs only allowed names using a-z, 0-9, . and - (and even then with restrictions on where . and - could be). _ was originally not a valid character in a domain name. IIRC this was never really enforced, and it was at least a little bit relaxed in later days, but I'm not quite sure all those symbols are actually allowed in a strict interpretation of the specs.
    – jcaron
    Mar 13, 2020 at 9:03
  • 4
    @jcaron I think you may be mixing up domain names in general (what the DNS protocol itself supports, not very strict) and hostnames (required in specific contexts, quite strict). Hostnames have these more strict rules that you refer to and still do not allow things like _. In the context of for instance an http url, a hostname is required and thus most domain names follow hostname rules.
    – Håkan Lindqvist
    Mar 13, 2020 at 9:47
  • @HåkanLindqvist And yet A records, the default of both nslookup and dig are for hosts, so the name should be an hostname and not a domain name. Such an explicit A record would hence be refused in a zonefile by any given standard nameserver.
    – Patrick Mevzek
    Mar 14, 2020 at 4:55
17

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

Improve this answer
5
  • yes it;s a http request which is supposed (in my understanding of course) to fail due to it's structure so that's what led me to try a dig and see what exactly is their intention with this code. I'm still unsure as to why they did it this way though since they use it to see if endpoints are alive - they could have used anything else - still a nice study for me.
    – Romeo Mihalcea
    Mar 12, 2020 at 23:30
  • Haven't look at the code, but it may be a way to detect installations with a captive portal and those with a DNS server that "catches" invalid queries for monetization purposes.
    – jcaron
    Mar 13, 2020 at 8:58
  • 1
    @RomeoMihalcea The structure looks fine. The name nowhere may not resolve, though.
    – Håkan Lindqvist
    Mar 13, 2020 at 9:40
  • @HåkanLindqvist It may resolve if the client box has such an entry in /etc/hosts or equivalent, or if the resolver tries to append a default domain in such cases, or one runs this domain on one's local DNS server, or - perhaps the safest method - if one is willing to throw a lot of money at IANA and sponsor a new TLD named nowhere ;)
    – Hagen von Eitzen
    Mar 14, 2020 at 7:55
  • @HåkanLindqvist I can't think of a good purpose, though a nefarious purpose might be in a phishing email, with a link to a legitimate-looking address like yourbank.com/login.html?name=totallylegit.dns.nextdns.io
    – Criggie
    Mar 14, 2020 at 10:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .