@@ -59,13 +62,13 @@ requirement for the resolving even when the target is reachable using IPv6.
Quick recap
Connecting to a website is easy, right? You type in the name, you get the front page.
OK, it is a bit harder: the computer needs an IP address, so we need to use
this magic box called DNS. The flow looks something like this:
And for IPv6-only everything on the picture has to have IPv6 connectivity and AAAA DNS records.
@@ -78,7 +81,7 @@ are well-known protocols like NAT64 with DNS64 to do that in a standard and
lightweight manner.
In that case, the connection looks like this:
You might already know that you need some workaround like this to reach GitHub.
@@ -93,15 +96,16 @@ the missing piece in the puzzle, though.)
Enter DNS
Our picture has one unexplored magic box: the DNS. As per the definition (which
I just made up and was not bothered to even fully formulate):
-
> yada yada distributed database of records attached to the strings – domain
-names. The records hold various information about the domain depending on the type.
+
+yada yada distributed database of records attached to the strings – domain
+names. The records hold various information about the domain depending on the type.
There are three interesting types of records: A records give IPv4 addresses,
AAAA give IPv6 addresses and NS give names of servers who know about the
particular subtree of the database. And to actually resolve the final AAAA
record the (recursive) resolver starts at the root zone and tries to find
the answer. The resolution algorithm can be visualised like this:
There is one extra tricky bit: the NS records contain names, not addresses,
@@ -109,7 +113,8 @@ so when resolving we need two queries for each layer (very simplified):
first we ask for the final domain (blog.ledoian.cz) and get a NS record
(when the server does not have the answer) and then we need to ask for the A or
AAAA record of the name from that record, so that we can connect to the server
-mentioned in the NS record.
+mentioned in the NS record. (This allows a nameserver to be made redundant
+and/or reside on other types of network.)
You might start to see the issue. When the DNS was just a black box, we could
paint the whole picture green and call it a day. And from the regular user's
point of view, that is the case, just use some public DNS like 1.1.1.1, 8.8.8.8
@@ -258,7 +263,7 @@ $ dig ns0.wikimedia.org AAAA
AAAA records. This is the case for all three nameservers. And here is the
ultimate picture of what is happening and what goes wrong.
Also note that the connection from the laptop to the DNS resolver may in fact
@@ -300,7 +305,7 @@ tree is deep and so is the resolution of this problem.
We have seen there may be multiple NS records for a domain and thus
multiple nameservers. This is good for redundancy. But this does not mean that
the servers will have the same records – they are only supposed to give
-equivalent answers.
+equivalent answers (as far as I know).
I have come across a silly misconfiguration: a domain which has several
nameservers, which serve a slightly different set of NS records for its
subdomain. Specifically, the servers which were only reachable using IPv4 were
@@ -308,7 +313,7 @@ subdomain. Specifically, the servers which were only reachable using IPv4 were
subdomain, which, incidentally, was the only one that was IPv6-capable.
So, while all the correct records were present in DNS (somewhat/somewhere), this still
meant that IPv6-only resolution was doomed to fail because the IPv6 nameserver
-chain was broken.
+chain was broken. (This has already been fixed.)