LEdoian
/
blog
1
0
Fork 0
Code Releases Activity

render

Browse Source
pub/forgetting-dns6
LEdoian 1 year ago
parent 4253559cd5
commit 3cfae2f1a8
2 changed files with 31 additions and 32 deletions
Show Stats Download Patch File Download Diff File

61
output/drafts/forgetting-dns6.html
Unescape Escape View File

@ -61,12 +61,12 @@ this magic box called DNS. The flow looks something like this:</p>
<object data="../images/forgetting-dns6/image2.svg" style="width: 50%;" type="image/svg+xml"></object> <object data="../images/forgetting-dns6/image2.svg" style="width: 50%;" type="image/svg+xml"></object>
<p class="caption">Slightly better, now we at least know the machine-readable address.</p> <p class="caption">Slightly better, now we at least know the machine-readable address.</p>
</div> </div>
<p>And for IPv6-only, everything on the picture has to have IPv6 connectivity and AAAA DNS records.</p> <p>And for IPv6-only everything on the picture has to have IPv6 connectivity and AAAA DNS records.</p>
<div class="section" id="reaching-ipv4-land-from-ipv6-only"> <div class="section" id="reaching-ipv4-land-from-ipv6-only">
<h3>Reaching IPv4 land from IPv6-only</h3> <h3>Reaching IPv4 land from IPv6-only</h3>
<p>There are :s:few many sites that still only support IPv4. To reach them, we <p>There are few^H^H^Hmany sites that still only support IPv4. To reach them, we
need someone, who can reach both the IPv4- and IPv6-land, to go there on our need someone who can reach both the IPv4- and IPv6-land to go there on our
behalf – a proxy. This proxy can be ad-hoc (I often use <tt class="docutils literal">ssh <span class="pre">-D</span></tt>), or there behalf – a proxy. This proxy can be ad-hoc (I often use <tt class="docutils literal">ssh <span class="pre">-D</span></tt>) or there
are well-known protocols like NAT64 with DNS64 to do that in a standard and are well-known protocols like NAT64 with DNS64 to do that in a standard and
lightweight manner. <a class="footnote-reference" href="#nat44" id="footnote-reference-1">[1]</a> lightweight manner. <a class="footnote-reference" href="#nat44" id="footnote-reference-1">[1]</a>
In that case, the connection looks like this:</p> In that case, the connection looks like this:</p>
@ -75,12 +75,11 @@ In that case, the connection looks like this:</p>
<p class="caption">And now we can reach the whole internet.</p> <p class="caption">And now we can reach the whole internet.</p>
</div> </div>
<p>You might already know that you need some workaround like this to reach GitHub. <p>You might already know that you need some workaround like this to reach GitHub.
What I think you didn't know, you need similar workaround to reach the Wikipedia.</p> What I think you might not know, you need similar workaround to reach the Wikipedia.</p>
<p>Disclaimer: While I am sad that GitHub lives in the past and it is stupid that <p>Disclaimer: I like Wikipedia and this is not meant to shame them, just use as
they do not have IPv6, I do not want to shame Wikipedia in particular. an example. I am aware of several other sites suffering from the same problem,
It is just an example I found out recently. I am aware of several other including at least one IPv6 test. <a class="footnote-reference" href="#test-aaaa" id="footnote-reference-2">[2]</a> (It would be nice if they added
sites suffering from the same problem, including at least one IPv6 test. <a class="footnote-reference" href="#test-aaaa" id="footnote-reference-2">[2]</a> (It would the missing piece in the puzzle, though.)</p>
be nice if they added the missing piece in the puzzle, though.)</p>
</div> </div>
</div> </div>
<div class="section" id="enter-dns"> <div class="section" id="enter-dns">
@ -88,18 +87,18 @@ be nice if they added the missing piece in the puzzle, though.)</p>
<p>Our picture has one unexplored magic box: the DNS. As per the definition (which <p>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):</p> I just made up and was not bothered to even fully formulate):</p>
<p>&gt; yada yada distributed database of records attached to the strings – domain <p>&gt; yada yada distributed database of records attached to the strings – domain
names. The records hold various information about the domain, depending on the type.</p> names. The records hold various information about the domain depending on the type.</p>
<p>There are three interesting types of records: A records give IPv4 addresses, <p>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 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 particular subtree of the database. And to actually resolve the final AAAA
record, the (recursive) resolver starts at the <em>root zone</em> and tries to find record the (recursive) resolver starts at the <em>root zone</em> and tries to find
the answer. <a class="footnote-reference" href="#dns-simplification" id="footnote-reference-3">[3]</a> The resolution algorithm can be visualised like this:</p> the answer. <a class="footnote-reference" href="#dns-simplification" id="footnote-reference-3">[3]</a> The resolution algorithm can be visualised like this:</p>
<div class="figure"> <div class="figure">
<object data="../images/forgetting-dns6/image4.svg" style="width: 100%;" type="image/svg+xml"></object> <object data="../images/forgetting-dns6/image4.svg" style="width: 100%;" type="image/svg+xml"></object>
<p class="caption">Yeah, it's a mess.</p> <p class="caption">Yeah, it's a mess.</p>
</div> </div>
<p>There is one extra tricky bit: the NS records contain <em>names</em>, not addresses, <p>There is one extra tricky bit: the NS records contain <em>names</em>, not addresses,
so when resolving, we need <em>two</em> queries for each layer (very simplified): so when resolving we need <em>two</em> queries for each layer (very simplified):
first we ask for the final domain (<tt class="docutils literal">blog.ledoian.cz</tt>) and get a NS record first we ask for the final domain (<tt class="docutils literal">blog.ledoian.cz</tt>) and get a NS record
(when the server does not have the answer) and then we need to ask for the A or (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 AAAA record of the name from that record, so that we can connect to the server
@ -109,7 +108,7 @@ 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 point of view, that is the case, just use some public DNS like 1.1.1.1, 8.8.8.8
or 9.9.9.9. Oh, right, I meant these easy-to-remember addresses: or 9.9.9.9. Oh, right, I meant these easy-to-remember addresses:
2606:4700:4700::1111, 2001:4860:4860::8888 and 2620:fe::fe, respectively. The 2606:4700:4700::1111, 2001:4860:4860::8888 and 2620:fe::fe, respectively. The
point is, they will give you the answer, because they are dual-stack, not IPv6-only.</p> point is, they will give you the answer because they are dual-stack, not IPv6-only.</p>
<p>In a way, those servers (or other dual-stack resolvers) act like another proxy, <p>In a way, those servers (or other dual-stack resolvers) act like another proxy,
similar to the SSH, NAT64 and NAT44 ones mentioned earlier. This may not be similar to the SSH, NAT64 and NAT44 ones mentioned earlier. This may not be
much of a problem for many people. But if you have any reason to use your own much of a problem for many people. But if you have any reason to use your own
@ -182,7 +181,7 @@ en.wikipedia.org. 86400 IN CNAME dyna.wikimedia.org.
;; Received 94 bytes from 208.80.153.231#53(ns1.wikimedia.org) in 132 ms ;; Received 94 bytes from 208.80.153.231#53(ns1.wikimedia.org) in 132 ms
</pre> </pre>
<p>Hey, there are IPv4 addresses in there! I know, this is cheating, the output is <p>Hey, there are IPv4 addresses in there! I know, this is cheating, the output is
run from a dual-stack machine. But we can still simulate IPv6-only resolution from a dual-stack machine. But we can still simulate IPv6-only resolution
by adding <tt class="docutils literal"><span class="pre">-6</span></tt> flag:</p> by adding <tt class="docutils literal"><span class="pre">-6</span></tt> flag:</p>
<pre class="literal-block"> <pre class="literal-block">
$ dig en.wikipedia.org AAAA +trace -6 $ dig en.wikipedia.org AAAA +trace -6
@ -221,7 +220,7 @@ couldn't get address for 'ns2.wikimedia.org': not found
dig: couldn't get address for 'ns0.wikimedia.org': no more dig: couldn't get address for 'ns0.wikimedia.org': no more
</pre> </pre>
<p>Some of those IPv4 addresses were benign – the respective servers are reachable <p>Some of those IPv4 addresses were benign – the respective servers are reachable
both using IPv4 and IPv6 address, or there is an alternative server that is both using IPv4 and IPv6 address or there is an alternative server that is
reachable using IPv6. That is the case for the root nameserver – in the second reachable using IPv6. That is the case for the root nameserver – in the second
case, we used C, which has IPv6 address (2001:500:2::c). In fact, the M server case, we used C, which has IPv6 address (2001:500:2::c). In fact, the M server
also has IPv6 address, but dig chose the IPv4 one (it should not matter):</p> also has IPv6 address, but dig chose the IPv4 one (it should not matter):</p>
@ -239,8 +238,8 @@ wikipedia.org. 86400 IN NS ns0.wikimedia.org.
wikipedia.org. 86400 IN NS ns1.wikimedia.org. wikipedia.org. 86400 IN NS ns1.wikimedia.org.
wikipedia.org. 86400 IN NS ns2.wikimedia.org. wikipedia.org. 86400 IN NS ns2.wikimedia.org.
</pre> </pre>
<p>This resolution is the last one that worked in IPv6-only mode, because none of <p>This is the last answer that we could get on an IPv6-only network, because none of
these three servers has AAAA record (some of them may have IPv6, which we do not learn about):</p> these three servers has AAAA record (some of them may have IPv6 address unknown to us):</p>
<pre class="literal-block"> <pre class="literal-block">
$ dig ns0.wikimedia.org AAAA $ dig ns0.wikimedia.org AAAA
[…] […]
@ -262,7 +261,7 @@ the final DNS resolver can have dual-stack connectivity.</p>
<div class="section" id="the-problems-with-this-state"> <div class="section" id="the-problems-with-this-state">
<h2>The problems with this state</h2> <h2>The problems with this state</h2>
<p>So, what is the deal. We <em>just</em> need to have a dual-stack DNS resolver <p>So, what is the deal. We <em>just</em> need to have a dual-stack DNS resolver
somewhere, and that's it, no? Well, yes but actually no.</p> somewhere, and that's it, no? Well, yes but actually yes.</p>
<p>There are two problems with this: First, this means that any new ISP needs to <p>There are two problems with this: First, this means that any new ISP needs to
have <em>at least some</em> IPv4 address, even if they intend to just use IPv6 have <em>at least some</em> IPv4 address, even if they intend to just use IPv6
services. IPv4 addresses are scarce, <a class="reference external" href="https://blog.apnic.net/2021/12/16/opinion-ipv4-address-markets/">expensive</a> and small services. IPv4 addresses are scarce, <a class="reference external" href="https://blog.apnic.net/2021/12/16/opinion-ipv4-address-markets/">expensive</a> and small
@ -271,7 +270,7 @@ which is not great both from the
new ISP's and from overal routing's point of view. It also hinders IPv6 new ISP's and from overal routing's point of view. It also hinders IPv6
deployment and postpones IPv4 abandonment, needlessly.</p> deployment and postpones IPv4 abandonment, needlessly.</p>
<p>The second issue is that this is not very visible. We are building IPv6 world, <p>The second issue is that this is not very visible. We are building IPv6 world,
but deep inside, it still relies on IPv4, which might lead to great surprise but deep inside it still relies on IPv4, which might lead to great surprise
when we start cutting off IPv4 internet. And it might lead to false sense of when we start cutting off IPv4 internet. And it might lead to false sense of
having IPv6 deployed, which is not true to the whole extent.</p> having IPv6 deployed, which is not true to the whole extent.</p>
<p>Insert &quot;It was DNS&quot; meme here.</p> <p>Insert &quot;It was DNS&quot; meme here.</p>
@ -280,18 +279,18 @@ having IPv6 deployed, which is not true to the whole extent.</p>
<h2>Solution</h2> <h2>Solution</h2>
<p>The solution of this state is simple: get IPv6 connectivity to your <p>The solution of this state is simple: get IPv6 connectivity to your
authoritative DNS server (or use another) and do not forget to add an AAAA authoritative DNS server (or use another) and do not forget to add an AAAA
record for it in DNS. If the DNS server already has IPv6, it is probably just record for it in DNS. If the DNS server already has IPv6 it is probably just
adding a single line to the zone file (and a second one for the DNSSEC a matter of adding a single line to the zone file (and a second one for the DNSSEC
signature), which should not be a big deal.</p> signature), which should not be a big deal.</p>
<p>Unfortunately, this needs to be done for the whole DNS chain. <p>Unfortunately, this needs to be done for the whole DNS chain.
Especially domain names at universities are infamous for very nested domains. Especially domain names at universities are infamous for very nested domains.
A domain name may looks like A domain name may look like
<tt class="docutils literal"><span class="pre">machine.department.location.faculty.university.some-common.suffix</span></tt>. That <tt class="docutils literal"><span class="pre">machine.department.location.faculty.university.some-common.suffix</span></tt>. That
tree is deep, and so is the resolution of this problem.</p> tree is deep and so is the resolution of this problem.</p>
</div> </div>
<div class="section" id="amusing-bug-of-almost-good-deployment"> <div class="section" id="amusing-bug-of-almost-good-deployment">
<h2>Amusing bug of almost good deployment</h2> <h2>Amusing bug of almost good deployment</h2>
<p>We have seen there may be multiple NS records for a domain, and thus <p>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 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 the servers will have the same records – they are only supposed to give
equivalent answers.</p> equivalent answers.</p>
@ -301,7 +300,7 @@ subdomain. Specifically, the servers which were only reachable using IPv4 were
<em>exactly</em> the servers that knew about one additional nameserver for the <em>exactly</em> the servers that knew about one additional nameserver for the
subdomain, which, incidentally, was the <em>only</em> one that was IPv6-capable.</p> subdomain, which, incidentally, was the <em>only</em> one that was IPv6-capable.</p>
<p>So, while all the correct records were present in DNS (somewhat/somewhere), this still <p>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 meant that IPv6-only resolution was doomed to fail because the IPv6 nameserver
chain was broken.</p> chain was broken.</p>
<hr class="docutils" /> <hr class="docutils" />
<table class="docutils footnote" frame="void" id="nat44" rules="none"> <table class="docutils footnote" frame="void" id="nat44" rules="none">
@ -309,7 +308,7 @@ chain was broken.</p>
<tbody valign="top"> <tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-1">[1]</a></td><td>This is very much the same as when you try to reach the <tr><td class="label"><a class="fn-backref" href="#footnote-reference-1">[1]</a></td><td>This is very much the same as when you try to reach the
IPv4-public-land from IPv4-private-land, that is, from a private range of IP IPv4-public-land from IPv4-private-land, that is, from a private range of IP
addresses. This is called either just NAT, or NAT44, meaning IPv4-to-IPv4 NAT.</td></tr> addresses. This is called either just NAT, or NAT44 to denote IPv4-to-IPv4 NAT.</td></tr>
</tbody> </tbody>
</table> </table>
<table class="docutils footnote" frame="void" id="test-aaaa" rules="none"> <table class="docutils footnote" frame="void" id="test-aaaa" rules="none">
@ -322,9 +321,9 @@ record, lol.</td></tr>
<table class="docutils footnote" frame="void" id="dns-simplification" rules="none"> <table class="docutils footnote" frame="void" id="dns-simplification" rules="none">
<colgroup><col class="label" /><col /></colgroup> <colgroup><col class="label" /><col /></colgroup>
<tbody valign="top"> <tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#footnote-reference-3">[3]</a></td><td>In my example, there is a recursive DNS resolver external to my machine, <tr><td class="label"><a class="fn-backref" href="#footnote-reference-3">[3]</a></td><td>In my example, there is a single recursive DNS
in order not to complicate it too much. Yes, the real deployment is often resolver external to my machine in order not to complicate it too much.
trickier.</td></tr> The real deployment is often trickier.</td></tr>
</tbody> </tbody>
</table> </table>
<table class="docutils footnote" frame="void" id="dns-behind-nat64" rules="none"> <table class="docutils footnote" frame="void" id="dns-behind-nat64" rules="none">

2
output/feeds/all.atom.xml
Unescape Escape View File

@ -1,2 +1,2 @@
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom"><title>LEdoian's Blog</title><link href="https://blog.ledoian.cz/" rel="alternate"></link><link href="https://blog.ledoian.cz/feeds/all.atom.xml" rel="self"></link><id>https://blog.ledoian.cz/</id><updated>2023-10-30T03:04:30Z</updated></feed> <feed xmlns="http://www.w3.org/2005/Atom"><title>LEdoian's Blog</title><link href="https://blog.ledoian.cz/" rel="alternate"></link><link href="https://blog.ledoian.cz/feeds/all.atom.xml" rel="self"></link><id>https://blog.ledoian.cz/</id><updated>2023-10-30T12:11:23Z</updated></feed>
Write Preview
Loading…
Cancel
Save