DNS resolution when there is no A-record

Question

There are domains, that are registered in DNS with a SOA-record only, but without any A-record (or any other records):

> dig wien.eu

; <<>> DiG 9.9.7-P3 <<>> wien.eu
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51354
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wien.eu.           IN  A

;; AUTHORITY SECTION:
wien.eu.        1922    IN  SOA dns1.magwien.gv.at. hostmaster.magwien.gv.at. 2013082700 10800 3600 604800 86400

;; Query time: 134 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Sat Dec 02 19:45:19 CET 2017
;; MSG SIZE  rcvd: 101

^{What looks like an A record is just a comment (it starts with a semicolon). Even if it wasn't a comment, it would be malformed (i.e. not an A record) because it contains no IP address.}

Most commands, that usually resolve domain-names (like ping, telnet and others) using DNS will fail if there is nothing but a SOA entry (and lots of comments and empty lines).

Also many webbrowsers are unable to open a website on such a SOA-only-domain, like http://wien.eu, among them:

• Google Chrome
• Opera
• Tor Browser

But there are browsers that will open a website if you enter such a domain name:

• Safari
• Firefox

^{I couldn't test Internet Explorer, because I use Mac OS, and it's not available there.}
In case of the given example they redirect to another URL (which btw. looks like a meaningful way to resolve the given URL, which makes me believe to be the desired behavior).

I wonder, what Safari and Firefox do to perform this miracle, that other browsers and tools can't do.

btw: I thought to know how DNS works, and I thought, this would mean, that SOA-only-domains like wien.eu can't be resolved to an IP-address. But Safari and Firefox prove the opposite.

Addendum in reaction to an answer.

All 5 browsers used in my test are the newest versions, and all of them run on the same computer (iMac with Mac OS X 10.13 High Sierra). So they all use exactly the same Operating System and they also use exactly the same DNS-Server.

And there is no AAAA-Record in the zone-file (as you can see in the quoted output of dig above).

And if you can't believe it: Try it out. Use any tool you want to check the DNS settings of wien.eu and try to open it in two different browser that belong to each of the both groups listed above.

Answer 1

I don't believe other browsers will be able to resolve the domain (unless there are CNAME or AAAA records which help DNS work out where to go next, and should be equally recognised by any browser).

Some possible explanations of the seen behaviour -

• Cached results being used as a fall back, but not available in all browsers.

• Different nameservers being picked with different zone file information (possibly split DNS or DNS caching)

• Hosts file entries on some computers but not others, or a search domain which can modify DNS fallback entries.

• Use if a caching proxy - possibly an ISP level transparent proxy.

• A bit if a guess, but if there is an AAAA records there may be browser and/or OS limitations handling the IPV6 resource.

It's relevant that web browsers don't do DNS resolution themselves, rather they make an IS call, and let the IS handle it. AFAIK this is true if all browsers.

Updated answer specific for this server, and in light of additional information

One of the possible explanations in my earlier answer "Different nameservers being picked with different zone file information (possibly split DNS or DNS caching)" was correct.

Doing the identical query twice to the same authorative nameserver yielded different results as follows:

davidgo@davidgo-Precision-T1500:~$ dig @dns1.wien.at wien.at

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @dns1.wien.at wien.at
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47939
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wien.at.           IN  A

;; ANSWER SECTION:
wien.at.        300 IN  A   217.149.229.10

;; AUTHORITY SECTION:
wien.at.        86400   IN  NS  ns11.govix.at.
wien.at.        86400   IN  NS  ns5.univie.ac.at.
wien.at.        86400   IN  NS  dns1.magwien.gv.at.
wien.at.        86400   IN  NS  dns1.wien.at.

;; ADDITIONAL SECTION:
dns1.magwien.gv.at. 86400   IN  A   217.149.228.128
dns1.wien.at.       86400   IN  A   217.149.229.128

;; Query time: 278 msec
;; SERVER: 217.149.229.128#53(217.149.229.128)
;; WHEN: Sun Dec 03 11:27:55 NZDT 2017
;; MSG SIZE  rcvd: 186

davidgo@davidgo-Precision-T1500:~$ dig @dns1.wien.at wien.eu -t any 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @dns1.wien.at wien.eu -t any
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56418
;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;wien.eu.           IN  ANY

;; ANSWER SECTION:
wien.eu.        86400   IN  SOA dns1.magwien.gv.at. hostmaster.magwien.gv.at. 2013082700 10800 3600 604800 86400
wien.eu.        86400   IN  NS  dns1.magwien.gv.at.
wien.eu.        86400   IN  NS  dns1.wien.at.

;; ADDITIONAL SECTION:
dns1.magwien.gv.at. 86400   IN  A   217.149.228.128
dns1.wien.at.       86400   IN  A   217.149.229.128

;; Query time: 277 msec
;; SERVER: 217.149.229.128#53(217.149.229.128)
;; WHEN: Sun Dec 03 11:28:15 NZDT 2017
;; MSG SIZE  rcvd: 171

This definately means there is an issue with the setup of the nameservers, but could be any number of things, including issues with a hidden primary nameserver, issues with the actual nameserver, issues with some members of a DNS cluster or a combination of the above. Its worth noting that the returned nameserver records are also different.

I also believe that some nameserver caching is going on in the OS, as the query which returned a result actually returns to the browser quite seldom.

It is also noteworthy that your dig query was not done against an authorative nameserver - and many/most ISP's use load balanaced pools of nameservers behind a single IP address - each which could have different information due to zone caching. This is obvious if you do a query against (for example) 8.8.8.8 - Googles "primary" nameserver, multiple times, and watch the TTL bounce arround wildly depending on which backend nameserver you get. (the TTL is the number between the domain name and the "IN" in the SOA record, but it exists on all records. If there were only a single server, that number would decrease as the seconds go by until it jumps when it reaches 0 and does a new lookup.

Answer 2

I found the answer to my own question by capturing the IP-traffic.

In a nutshell

When firefox didn't get an IP-address for wien.eu, it asked (without any orders from the user or anyone else) for www.wien.eu instead (it joined the prefix www. to the original domain name). Since there is a valid A-record for this other domain, it got an answer (i.e. an IP-address), sent a HTTP GET to this site, got 301 redirect, and then loaded the redirected resource.

Obviously other browsers don't do this www-trick.

---

In detail

I used Kali Linux as Operating System, and there I started Firefox. I used Wireshark to capture the traffic. Here are my findings in detail:

Firefox asks for A and AAAA DNS-records for wien.eu and for wien.eu.localdomain and always gets the answer No such name. It asks its default gateway, which obviously also is a DNS server.

Firefox sends (time = 0.000):
1: Standard DNS-Query: wien.eu: type A, class IN
2: Standard DNS-Query: wien.eu: type AAAA, class IN

Firefox receives (time = 0.030):
3: (Response to 1): Standard DNS-Response: No such name A wien.eu
4: (Response to 2): Standard DNS-Response: No such name AAAA wien.eu

Firefox sends (time = 0.030):
5: Standard DNS-Query: wien.eu.localdomain: type A, class IN
6: Standard DNS-Query: wien.eu.localdomain: type AAAA, class IN

Firefox receives (time = 0.031):
7: (Response to 5): Standard DNS-Response: No such name A wien.eu.localdomain
8: (Response to 6): Standard DNS-Response: No such name AAAA wien.eu.localdomain

Then Firefox repeats exactly the same four queries and receives exactly the same responses (messages #9 to #16, time = 0.047, 0.053, 0.054, 0.054)

And again (messages #17 to #24, time = 0.057 to. 0.083)

And again (messages #25 to #32, time = 0.083 to. 0.095)

In round #5 Firefox adds the prefix www. to the domain name, and now it gets helpful answers:

Firefox sends (time = 0.113):
33: Standard DNS-Query: www.wien.eu: type A, class IN
34: Standard DNS-Query: www.wien.eu: type AAAA, class IN

Firefox receives (time = 0.140):
35: (Response to 33): Standard DNS-Response: 
Answers:
www.wien.eu: type CNAME, class IN, cname redirector.magwien.gv.at
redirector.magwien.gv.at: type A class IN, addr 217.149.229.45
Authorative nameservers
magwien.gv.at: type NS, class IN, ns ns11.govix.at.
magwien.gv.at: type NS, class IN, ns dns1.magwien.gv.at.
magwien.gv.at: type NS, class IN, ns ns5.univie.ac.at.
magwien.gv.at: type NS, class IN, ns dns1.wien.at.
Additional records
ns11.govix.at: type A, class IN, addr 192.76.243.11
ns11.govix.at: type AAAA, class IN, addr 2001:67c:133c::11
dns1.wien.at: type A, class IN, addr 217.149.229.128
dns1.magwien.gv.at: type A, class IN, addr 217.149.228.128
ns5.univie.ac.at: type A, class IN, addr 193.171.255.77
ns5.univie.ac.at: type AAAA, class IN, addr 2001:628:453:4305::53

36: (Response to 34): Standard DNS-Response:
Answers:
www.wien.eu: type CNAME, class IN, cname redirector.magwien.gv.at
Authorative nameservers
magwien.gv.at: type SOA, class IN, mname dns1.magwien.gv.at.

Since now Firefox has an IP address, it creates a TCP connection to this address (TCP handshake, messages #37-39). Then, in message #40, it sends an HTTP GET request to this destination:

GET / HTTP1.1
Host: www.wien.eu
(and some additional HTTP headers)

The server acknowledges this request (message #41) and then sends this answer in message #42:

301 Moved Permanently
Location: https://www.wien.gv.at/

The rest is clear:

• Firefox sends a TCP-acknowledge (message #43)
• Firefox asks for DNS-resolution for www.wien.gv.at (A and AAAA, messages #44 and #45)
• Firefox receives the answers (messages #46 and #47)
• Then Firefox starts the complicated HTTPS dialog to load the html page that it then displays.