diff options
author | uvok cheetah | 2025-01-12 16:51:37 +0100 |
---|---|---|
committer | uvok cheetah | 2025-01-12 16:51:37 +0100 |
commit | 20d1675bb56505d1ac22499c0175d2c678c688c2 (patch) | |
tree | fe69565b92a3ce4305ceb0b3140806c947bfe6c0 | |
parent | 04989aec35de8f45e689de0d7b5826fb1cf6fb6f (diff) |
Polish and Publish post: DNS
-rw-r--r-- | _posts/2025-01-12-2025-01-12-migrating-dns-servers.md (renamed from _drafts/migrating-dns-servers.md) | 93 |
1 files changed, 55 insertions, 38 deletions
diff --git a/_drafts/migrating-dns-servers.md b/_posts/2025-01-12-2025-01-12-migrating-dns-servers.md index 668356f..e64e2bc 100644 --- a/_drafts/migrating-dns-servers.md +++ b/_posts/2025-01-12-2025-01-12-migrating-dns-servers.md @@ -1,9 +1,9 @@ --- layout: post title: Migrating DNS servers -date: 2025-01-10 19:37 +0100 lang: en categories: tech +date: 2025-01-12 16:49 +0100 --- ## Preface @@ -15,8 +15,8 @@ categories: tech your domain) and * the (web) hosting service -can be three different entities / providers, even though for most beginner -projects these are the same. +can be three different entities, even though for most beginner 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 @@ -39,7 +39,7 @@ Quick and dirty glossary, for the purpose of reading this article. It's not * **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"). @@ -51,17 +51,18 @@ Quick and dirty glossary, for the purpose of reading this article. It's not 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. +* **NSEC, NSEC3**: Basically these are "negative replies", i.e. "this domain + does not exist". These are signed as well. 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. + names, etc.. * **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 (caching) DNS server can cache a record for 1 hour before checking with the - authoritative server again. + -> 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. @@ -72,8 +73,8 @@ Quick and dirty glossary, for the purpose of reading this article. It's not 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. -* **AXFR**: A request type for a Domain zone transfer. + tampered with, or because of wrong configuration. +* **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. @@ -95,9 +96,9 @@ myself) would receive bogus replies in that time. I want to avoid that. ## 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 -other TLDs and other registrars. +But, I think I found a solution for that. This are the steps which I had to take +for the registrar INWX and my uvokchee.de domain. The process might be different +for other TLDs and other registrars. 1. Download the zone data from the INWX web interface 1. Create the zone in PowerDNS and set various settings @@ -109,13 +110,17 @@ other TLDs and other registrars. pdnsutil secure-zone $zone pdnsutil set-presigned $zone pdnsutil set-meta $zone ALLOW-AXFR-FROM <ip of secondaries> + # optional? see below for a discussion + pdnsutil set-nsec3 $zone $parameters 1. Filter and import the zone. PowerDNS will actually complain about the NSEC3 records otherwise once you open the zone in your editor. + # any other regex that filters only NSEC3 records, but not RRSIG NSEC3, + # work as well grep -vw "IN NSEC3" ./dl-zone.txt > imp-zone.txt pdnsutil load-zone $zone ./imp-zone.txt - This should keep the RRSIGs for the NSEC3 records. This doesn't help with + This should keep the RRSIGs for the NSEC3 records. This doesn't help with the errors I receive later, though… 1. Set up the secondaries. I went with [Hurricane @@ -125,7 +130,7 @@ other TLDs and other registrars. zero-downtime migration. 1. Wait for the DNS provider to AXFR. 1. (optional) check with [dnsviz](https://dnsviz.net/) whether you get any - errors. You should set the nameserver on the "Analyze" tab, and then set the + errors. You should set the nameserver on the "Analyze" tab, and then set the "Additional trusted keys:" to what `dig example.com DNSKEY` tells you. At this point, I got warnings/errors regarding the "Denial of existence" / NSEC3 records, and some errors because the RRSIGs can't be checked. (Once @@ -164,19 +169,19 @@ other TLDs and other registrars. reply, it sends back an error. I imported the RRSIGs for these NSEC3 records, though, at least in a second - attempt. I tried all combinations of (set-nsec3|unset-nsec3) and (import - NSEC3-RRSIG|don't import NSEC3-RRSIG). All variants failed. I have no clue + attempt. I tried all combinations of `(set-nsec3|unset-nsec3)` and `(import + NSEC3-RRSIG|don't import NSEC3-RRSIG)`. All variants failed. I have no clue how this is supposed to work cleanly. [^7] 1. Wait at least 24 hours (TTLs, DNS propagation time). 1. Let PowerDNS output its own keys it generated for the zone. Unfortunately, `pdnsutil export-zone-dnskey $zone $keynr` *does not output a completely - valid record*, neither does `pdnsutil export-zone-ds $zone`. These outputs - are missing the TTLs in the second column, at least with PowerDNS 4.7.3 in - the Debian stable repos. You have to add those yourself. I saw some tools - like dnsviz break when you enter the records as-is. + valid record*, nor does `pdnsutil export-zone-ds $zone`. These outputs are + missing the TTLs in the second column, at least with PowerDNS 4.7.3 in the + Debian stable repos. You have to add those yourself. I saw some tools like + dnsviz break when you enter the records as-is. - **Important**, I had to temporarily run `unset-presigned $zone' (see + **Important**, I had to temporarily run `unset-presigned $zone` (see below) before running `pdnsutil export-zone-ds`, so PowerDNS actually outputs the hash of the new key(s)! Otherwise it will only show the current keys signature. Otherwise, you may also use online tools that convert the DNSKEY @@ -187,7 +192,9 @@ other TLDs and other registrars. * Delete all keys from the domain. * Add DNSSEC again for the domain, in manual mode. * Add DNSKEY and DS records of the old keys. - * Add keys, insert DNSKEY and DS records emitted by pdnsutil. + * Add key, insert DNSKEY and DS records emitted by pdnsutil for the new + key. + As far as I know, this will be sent to the parent zone. [^8] 1. After I got an email from INWX confirming the new DNSSEC entries, I ran dnsviz again and nearly got an heart attack, because there were a lot of @@ -196,21 +203,29 @@ other TLDs and other registrars. The DS RRset for the zone included algorithm 13 (ECDSAP256SHA256), but no RRSIG with algorithm 13 covering the RRset was returned in the response. -1. Wait at least 24 hours (TTLs, DNS propagation time). - Depeding on the - previous DS records TTL. \ - *I am currently at this step. Further steps are guesswork*. -1. `pdnsutil unset-presigned $zone`. I guess at this point you must or should + + I *think* dnsviz expects both `RRSIG`s, i.e. both keys must sign the replies? + That shouldn't have an effect on the reachability, otherwise the tool would + report BOGUS records? +1. Wait at least 24 hours (TTLs, DNS propagation time). - Depending on the + previous DS records TTL. +1. Switch to automatic signing by PowerDNS. I guess at this point you must or should * stop PowerDNS, [^5] + * `pdnsutil unset-presigned $zone`, + * `pdnsutil unset-nsec3 $zone`, * 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, - don't forget the NSEC3PARAM record), while also increasing the serial - (otherwise the AXFR might not take place), + the PowerDNS docs correctly, there will be trouble [^6] if you don't. Oh, + don't forget the NSEC3PARAM record, any leftover (C)DNSKEYS and (C)DS, + while also increasing the serial (otherwise the AXFR might not take + place), [^9] + * `pdnsutil rectify-zone $zone` * start PowerDNS, - * notify the secondaries -1. At this point, you should be done. + * (optional) notify the secondaries +1. At this point, you should be done. And I *guess* at this point you could + already delete the other DS/DNSKEY via the registrar? -By the way, I'll choose to use NSEC instead of NSEC3, seems like too much of a -headache for me. +By the way, I'll choose to use NSEC instead of NSEC3. NSEC3 seems like too much +of a headache for me, also, domain names are not secrets. ## Further references @@ -239,11 +254,13 @@ headache for me. [^7]: There are two GitHub issues similar to this: [#9263](https://github.com/PowerDNS/pdns/issues/9263) and - [#8892](https://github.com/PowerDNS/pdns/issues/8892) + [#8892](https://github.com/PowerDNS/pdns/issues/8892). [^8]: - Actually, I have no idea why IWNX wants me to enter both the DS and the + Actually, I have no idea why INWX wants me to enter both the DS and the DNSKEY. Only the DS gets entered in the DENIC servers. +[^9]: + e.g. `:g/\<\(RRSIG\|NSEC3PARAM\|DS\|CDS\|DNSKEY\|CDNSKEY\)\>/d` in vim. <!-- vim: set ft=markdown tw=80 ai tabstop=4 shiftwidth=4 expandtab: --> |