DNS: Fix h level, glossary, steps...

1 files changed, 83 insertions, 34 deletions

diff --git a/_drafts/migrating-dns-servers.md b/_drafts/migrating-dns-servers.md
index 26b69e4..ce587c4 100644
--- a/_drafts/migrating-dns-servers.md
+++ b/_drafts/migrating-dns-servers.md
@@ -6,7 +6,7 @@ lang: en
 categories: tech
 ---
 
-### Preface
+## Preface
 
 [As I posted on Mastodon](https://furry.engineer/@uvok/113780013806190576), 
 
@@ -21,58 +21,69 @@ projects these are the same.
 I either bought or migrated my domain over to [INWX](https://www.inwx.de/en)
 quite some while ago. However, their web interface for editing records is a bit
 clunky. And while they do provide an API, it's a bit awkward (XML based, and
-yes, there are ready-made packages for various programming languages). [1]
+yes, there are ready-made packages for various programming languages). [^1]
 
 With [DN42](https://blog.uvokchee.de/dn42.html), I already used
 [PowerDNS](https://doc.powerdns.com/authoritative/) a lot. I actually just use
-edit-zone and edit the zone[2] in an editor, that's my preferred way. Definitely
+edit-zone and edit the zone[^2] in an editor, that's my preferred way. Definitely
 preferred to some web interface. It would be nice to do this to my main domains
 as well. Also, this is another nice "have a technical task to procrastinate
 other stuff" thing ;3. Well, I like playing with tech. This is by no means
 essential.
 
-### Glossary
+## Glossary
 
 Quick and dirty glossary, for the purpose of reading this article. It's not
 100% accurate and complete, but should be enough to understand the article.
 
-* **Domain Name**: Basically "the name of the website in the address bar" (e.g.
-  "blog.uvokchee.de").
+* **Domain Name**: Basically "the name of a server" (what you see in the address
+  bar of the browser, e.g. "blog.uvokchee.de").
 * **DNS**: The "Domain Name System". Very simplified, translates domain names
-  to IP addresses (which computers use to connect to each other).
+  to IP addresses (which computers use to connect to each other). \
+  To be more precise, it's like a lookup in a database (-> DNS record).
 * **TLD**: Top-Level Domain. It's "the last part of the domain name" (e.g.
   ".de").
 * **Registry**: These run the TLDs.
 * **Registrar**: These sell you domain names from the registries. As an "end
   user", you can't talk to a registry yourself.
 * **DNSSEC**: DNS is a plain-text, insecure protocol, from way back when the
-  internet consistent of a handful of trustworthy people. DNSSEC tries to
-  prevent malicious parties from sending  wrong information in response to DNS
-  requests by signing the responses with a cryptographic key, of which the
+  internet consisted of a handful of trustworthy people. DNSSEC tries to prevent
+  malicious parties from sending wrong information in response to DNS requests.
+  It does so by signing the responses with a cryptographic key, of which the
   public part is stored in the registry.
 * **NSEC(3)**: Basically signs "negative replies", i.e. "this domain does not
   exist". If not present, malicious parties could send back replies to sites
   they don't want to be reachable as "doesn't exist" all the time.
+* **Zone**: A zone file contains all the DNS records for a specific domain.
+* **DNS record**: Like "a row in the database" which belongs to your domain. Can
+  be an address, but also things like text, PGP keys, pointer to other domain
+  names.
 * **TTL**: Time To Live. The time (in seconds) a reply to a DNS request may be
-  cached by a server.  For example, a TTL of 3600 seconds means that a DNS
-  server can cache a record for 1 hour before checking with the authoritative
-  server again.
+  cached by a server. For example, a TTL of 3600 seconds means that a (caching)
+  DNS server can cache a record for 1 hour before checking with the
+  authoritative server again.
 * **Authoritative Server:** The DNS server that holds the official and most
   up-to-date records for a specific domain.
+    * **Primary**: The primary source of truth.
+    * **Secondary**: Mirrors the information from the primary. There can be more
+      than one.
+* **Recursion**: DNS is hierarchical. There are fixed "root servers" which serve
+  the nameservers for all the TLDs. The TLDs provide the nameservers for the
+  domains "below them". A recursive server "walks along this path" to answer
+  requests. At some point, it arrives at the authoritative server.
 * **Bogus reply**: A reply with invalid signature, either because it has been
   tampered with, or because of misconfiguration.
-* **Zone**: A zone file contains all the DNS records for a specific domain.
 * **AXFR**: A request type for a Domain zone transfer.
 * **Domain Zone Transfer**: The process of copying the contents of a zone from
   one DNS server to another.
 
-### Migration and DNSSEC
+## Migration and DNSSEC
 
 So, why not migrate my domain over to my PowerDNS setup? Well, I want some
 availability, and I don't trust myself enough not to fuck things up. When my
 server is shut down, DNS requests should still be answered. But hey, that's
 where secondaries come in! So, I manage the zone on my server, as primary, and
-let another provider mirror its contents. These will actually serve the zone.
+let another provider mirror its contents. These will actually "serve the zone".
 
 Now, only… there's the "problem" of DNSSEC, in conjunction with the DNS
 propagation time and TTLs. If I simply set the nameservers (in the de zone) to
@@ -80,9 +91,9 @@ a newly created zone by PowerDNS, the DNSSEC keys will be either not present,
 or different. I can't set *additional* keys at INWX easily, I can only switch
 to manual keys (by switching off DNSSEC first). Which would lead to a downtime
 of up to one day, because people requesting records from my domain (such as
-myself) would receive bogus replies in that time.
+myself) would receive bogus replies in that time. I want to avoid that.
 
-### Steps for migration
+## Steps for migration
 
 But, I think I found a solution for that. This is my plan, which for the
 registrar INWX and my uvokchee.de domain. The process might be different for
@@ -97,8 +108,7 @@ other TLDs and other registrars.
         pdnsutil set-kind $zone primary
         pdnsutil secure-zone $zone
         pdnsutil set-presigned $zone
-        pdnsutil set-meta $zone ALLOW-AXFR-FROM <whatever servers are \
-          secondaries>
+        pdnsutil set-meta $zone ALLOW-AXFR-FROM <ip of secondaries>
 1. Filter and import the zone. PowerDNS will actually complain about the NSEC3
    records otherwise once you open the zone in your editor.
 
@@ -118,13 +128,19 @@ other TLDs and other registrars.
    NSEC3 records, and some errors because the RRSIGs can't be checked. (Once
    you set a manual nameserver, the tool doesn't seem to check for the parent
    zone anymore? I'm unclear on that).
-1. Try to set the new nameservers (nsx.he.net) in the registry (e.h. DENIC) via
+1. Try to set the new nameservers (nsx.he.net) in the registry (e.g. DENIC) via
    the INWX web interface ("external nameservers").
-1. Receive an "UPDATE FAILED". Read the error message. Realize you fucked up.
+1. Receive an "UPDATE FAILED". Read the error message.
+
+       ERROR: 53300102912 Nameserver error [ERROR: 118 Inconsistent set of NS
+       RRs (NS, IP, NS host names) (ns5.he.net, 2001:470:500::2, ['ns.inwx.de',
+       'ns2.inwx.de', 'ns3.inwx.eu'])]
+   
+   Realize you fucked up.
    You need to set the new nameservers within your own zone first. This seems
    to be a requirement for DENIC at any case.
 1. Add the NS entries to the HE nameservers within your zone in the INWX web
-   interface. [4]
+   interface. [^4]
 1. Download and import the zone file again. Wait for the AXFR.
 1. Retry sending the nameservers to the registry. Wait until success.
 1. At this point, I checked again with dnsviz. With the default options,
@@ -136,6 +152,18 @@ other TLDs and other registrars.
         NSEC3 proving non-existence of l2v1y.7t5is.uvokchee.de/A: No RRSIG covering the RRset was returned in the response. See RFC 4035, Sec. 3.1.1. (216.218.130.2, 216.218.131.2, 216.218.132.2, 2001:470:100::2, 2001:470:200::2, 2001:470:300::2, UDP_-_EDNS0_4096_D_KN)
         NSEC3 proving non-existence of uvokchee.de/CNAME: No RRSIG covering the RRset was returned in the response. See RFC 4035, Sec. 3.1.1. (216.218.130.2, 216.218.131.2, 216.218.132.2, 2001:470:100::2, 2001:470:200::2, 2001:470:300::2, UDP_-_EDNS0_4096_D_KN)
 
+    As of 2015-01-11, I read the [PowerDNS
+    docs](https://doc.powerdns.com/authoritative/dnssec/migration.html#from-existing-dnssec-non-powerdns-setups-pre-signed)
+    again. Specifically, I need to set `pdnsutil set-nsec3 $zone <whatever
+    NSEC3PARAM says>`. Then, PowerDNS gives back SERVFAILs, because, of course,
+    PowerDNS can't sign the reply, because it doesn't have the keys to sign the
+    NSEC3 replies (??? I guess ???). So now, instead of sending back an unsigned
+    reply, it sends back an error.
+
+    Further: PoweDNS *refuses to import NSEC3 records*. It wants to generate them
+    itself. If I understood things correctly, that would be no problem if it
+    simply imported the zone file with the prepared NSEC3 records?
+
 1. Wait at least 24 hours (TTLs, DNS propagation time). \
    *I am currently at this step. Further steps are guesswork*.
 1. Let PowerDNS output its own keys it generated for the zone.  Unfortunately,
@@ -144,6 +172,9 @@ other TLDs and other registrars.
    are missing the TTLs. At least with PowerDNS 4.7.3 in the Debian stable
    repos. I saw some tools like dnsviz break when you enter the records as-is.
    No idea what would happen with INWX.
+
+   I am not sure, maybe I would have to temporarily run `unset-presigned' (see
+   below) so PowerDNS actually outputs the new keys?
 1. Have a copy of the *current* DS / DNSKEY records as well (`dig` is your
    friend).
 1. Set the DNSSEC from "auto" to "manual" in the INWX web interface. Enter *both
@@ -152,9 +183,9 @@ other TLDs and other registrars.
    As far as I know, this will be sent to the parent zone.
 1. Wait at least 24 hours (TTLs, DNS propagation time).
 1. `pdnsutil unset-presigned $zone`. I guess at this point you must or should
-      * stop PowerDNS, [5]
+      * stop PowerDNS, [^5]
       * edit the zone (clearing out the RRSIGs you imported. If I understood
-        the PowerDNS docs correctly, there'll be trouble [6] if you don't. Oh,
+        the PowerDNS docs correctly, there'll be trouble [^6] if you don't. Oh,
         don't forget the NSEC3PARAM record), while also increasing the serial
         (otherwise the AXFR might not take place),
       * start PowerDNS,
@@ -164,12 +195,30 @@ other TLDs and other registrars.
 By the way, I'll choose to use NSEC instead of NSEC3, seems like too much of a
 headache for me.
 
-[1] Okay, it's not like I edit my records that often. \
-[2] For the purposes of this blog article, I think you can freely substitute
-zone with domain in your head, I probably won't use the words correctly 100% of
-the time either. \
-[4] I think that shouldn't to any damage. DNS recursion should always ask the
-parent zone? \
-[5] Avoiding a spurious notify or AXFR directly after editing? No idea if
-needed. \
-[6] such as duplicate RRSIG replies.
+## Further references
+
+* [PowerDNS docs](https://doc.powerdns.com/authoritative/)
+* IETF Draft: [Changing DNS Operators for DNSSEC signed
+  Zones](https://datatracker.ietf.org/doc/html/draft-koch-dnsop-dnssec-operator-change-06)
+
+## Footnotes
+
+[^1]: Okay, it's not like I edit my records that often.
+
+[^2]:
+    For the purposes of this blog article, I think you can freely substitute
+    zone with domain in your head, I probably won't use the words correctly 100% of
+    the time either.
+
+[^4]:
+    I think that shouldn't to any damage. DNS recursion should always ask the parent
+    zone?
+
+[^5]:
+    Avoiding a spurious notify or AXFR directly after editing? No idea if needed.
+
+[^6]: such as duplicate RRSIG replies.
+
+
+<!-- vim: set ft=markdown tw=80 ai tabstop=4 shiftwidth=4 expandtab: -->
+