Language fixups

content/forgetting-dns6.rst

@@ -33,14 +33,14 @@ this magic box called DNS. The flow looks something like this:
 
    Slightly better, now we at least know the machine-readable address.
 
-And for IPv6-only, everything on the picture has to have IPv6 connectivity and AAAA DNS records.
+And for IPv6-only everything on the picture has to have IPv6 connectivity and AAAA DNS records.
 
 Reaching IPv4 land from IPv6-only
 ---------------------------------
 
-There are :s:few many 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
-behalf – a proxy. This proxy can be ad-hoc (I often use ``ssh -D``), or there
+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
+behalf – a proxy. This proxy can be ad-hoc (I often use ``ssh -D``) or there
 are well-known protocols like NAT64 with DNS64 to do that in a standard and
 lightweight manner. [#nat44]_
 In that case, the connection looks like this:
@@ -51,13 +51,12 @@ In that case, the connection looks like this:
    And now we can reach the whole internet.
 
 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.
+What I think you might not know, you need similar workaround to reach the Wikipedia.
 
-Disclaimer: While I am sad that GitHub lives in the past and it is stupid that
-they do not have IPv6, I do not want to shame Wikipedia in particular.
-It is just an example I found out recently. I am aware of several other
-sites suffering from the same problem, including at least one IPv6 test. [#test-aaaa]_ (It would
-be nice if they added the missing piece in the puzzle, though.)
+Disclaimer: I like Wikipedia and this is not meant to shame them, just use as
+an example. I am aware of several other sites suffering from the same problem,
+including at least one IPv6 test. [#test-aaaa]_ (It would be nice if they added
+the missing piece in the puzzle, though.)
 
 Enter DNS
 =========
@@ -66,12 +65,12 @@ 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.
+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
+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
+record the (recursive) resolver starts at the *root zone* and tries to find
 the answer. [#dns-simplification]_ The resolution algorithm can be visualised like this:
 
 .. figure:: {static}/images/forgetting-dns6/image4.svg
@@ -80,7 +79,7 @@ the answer. [#dns-simplification]_ The resolution algorithm can be visualised li
    Yeah, it's a mess.
 
 There is one extra tricky bit: the NS records contain *names*, not addresses,
-so when resolving, we need *two* queries for each layer (very simplified):
+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
@@ -91,7 +90,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
 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
-point is, they will give you the answer, because they are dual-stack, not IPv6-only.
+point is, they will give you the answer because they are dual-stack, not IPv6-only.
 
 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
@@ -166,7 +165,7 @@ But we can dig deeper: let's see what servers we are really asking::
     ;; Received 94 bytes from 208.80.153.231#53(ns1.wikimedia.org) in 132 ms
 
 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 ``-6`` flag::
 
     $ dig en.wikipedia.org AAAA +trace -6
@@ -206,7 +205,7 @@ by adding ``-6`` flag::
 
 
 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
 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)::
@@ -224,8 +223,8 @@ are three nameservers::
     wikipedia.org.		86400	IN	NS	ns1.wikimedia.org.
     wikipedia.org.		86400	IN	NS	ns2.wikimedia.org.
 
-This resolution is the last one that worked in IPv6-only mode, because none of
-these three servers has AAAA record (some of them may have IPv6, which we do not learn about)::
+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 address unknown to us)::
 
     $ dig ns0.wikimedia.org AAAA
     […]
@@ -250,7 +249,7 @@ The problems with this state
 ============================
 
 So, what is the deal. We *just* need to have a dual-stack DNS resolver
-somewhere, and that's it, no? Well, yes but actually no.
+somewhere, and that's it, no? Well, yes but actually yes.
 
 There are two problems with this: First, this means that any new ISP needs to
 have *at least some* IPv4 address, even if they intend to just use IPv6
@@ -263,7 +262,7 @@ new ISP's and from overal routing's point of view. It also hinders IPv6
 deployment and postpones IPv4 abandonment, needlessly.
 
 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
 having IPv6 deployed, which is not true to the whole extent.
 
@@ -274,20 +273,20 @@ Solution
 
 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
-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
+record for it in DNS. If the DNS server already has IPv6 it is probably just
+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.
 
 Unfortunately, this needs to be done for the whole DNS chain.
 Especially domain names at universities are infamous for very nested domains.
-A domain name may looks like
+A domain name may look like
 ``machine.department.location.faculty.university.some-common.suffix``. That
-tree is deep, and so is the resolution of this problem.
+tree is deep and so is the resolution of this problem.
 
 Amusing bug of almost good deployment
 =====================================
 
-We have seen there may be multiple NS records for a domain, and thus
+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.
@@ -299,21 +298,21 @@ 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
+meant that IPv6-only resolution was doomed to fail because the IPv6 nameserver
 chain was broken.
 
 -----
 
 .. [#nat44] 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
-   addresses. This is called either just NAT, or NAT44, meaning IPv4-to-IPv4 NAT.
+   addresses. This is called either just NAT, or NAT44 to denote IPv4-to-IPv4 NAT.
 
 .. [#test-aaaa] There are several more tests that do not even have the AAAA
    record, lol.
 
-.. [#dns-simplification] In my example, there is a recursive DNS resolver external to my machine,
-   in order not to complicate it too much. Yes, the real deployment is often
-   trickier.
+.. [#dns-simplification] In my example, there is a single recursive DNS
+   resolver external to my machine in order not to complicate it too much.
+   The real deployment is often trickier.
 
 .. [#dns-behind-nat64] I have not yet tried to run a recursive DNS in a network
    with DNS64 and NAT64. Could be fun :-D My wild guess is that I would need