DNS delegation

DNS delegation

[Julien Lepiller]

[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

Hi,

we've already discussed that multiple times, we'd like to have a DNS
delegation for guix.gnu.org, so that we can manage the zone ourselves
without having to rely too much on fsf sysadmins.

Here is a patch (untested) that aims at doing that. I've configured
bayfront and berlin to be DNS authoritative servers. bayfront is the
master (it is the one that needs to be updated when a change happens in
the zone), and berlin is set as slave (it will automatically follow
changes in bayfront). I've enabled dnssec on bayfront, since it's the
one that's going to sign the zone, and transfer signatures to its slave.

Currently the zone (in modules/sysadmin/dns.scm) is incomplete. What
needs to be there?

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-hydra-Add-dns-services-for-guix.gnu.org.patch --]
[-- Type: text/x-patch, Size: 6960 bytes --]

From 331a85e469579c02a3fc338a6fb0bade3916c666 Mon Sep 17 00:00:00 2001
From: Julien Lepiller <julien@lepiller.eu>
Date: Mon, 4 Mar 2019 22:00:22 +0100
Subject: [PATCH] hydra: Add dns services for guix.gnu.org.

* hydra/bayfront.scm (services): Add knot-service.
* hydra/berlin.scm (services): Add knot-service.
* hydra/modules/sysadmin/dns.scm: New file.
---
 hydra/bayfront.scm             | 16 +++++++-
 hydra/berlin.scm               | 19 ++++++++-
 hydra/modules/sysadmin/dns.scm | 70 ++++++++++++++++++++++++++++++++++
 3 files changed, 101 insertions(+), 4 deletions(-)
 create mode 100644 hydra/modules/sysadmin/dns.scm

diff --git a/hydra/bayfront.scm b/hydra/bayfront.scm
index fae5cb5..6ec21f2 100644
--- a/hydra/bayfront.scm
+++ b/hydra/bayfront.scm
@@ -1,7 +1,7 @@
 ;; OS configuration for bayfront, the frontend of the compile farm.
 
-(use-modules (gnu) (guix) (sysadmin people) (sysadmin services))
-(use-service-modules base networking admin shepherd)
+(use-modules (gnu) (guix) (sysadmin people) (sysadmin services) (sysadmin dns))
+(use-service-modules base dns networking admin shepherd)
 (use-package-modules admin certs linux ssh tls vim package-management web wget)
 
 (define %sysadmins
@@ -124,6 +124,18 @@ Happy hacking!\n"))
 
                    (service ntp-service-type)
 
+                   ;; DNS
+                   (service knot-service-type
+                            (knot-configuration
+                              (zones (list (knot-zone-configuration
+                                             (inherit guix.gnu.org-zone)
+                                             (dnssec-policy "default")
+                                             (acl '("transfer-allow")))))
+                              (acls (list (knot-acl-configuration
+                                            (id "transfer-allow")
+                                            (address (list berlin-ip4))
+                                            (action '(transfer)))))))
+
                    (frontend-services %sysadmins
                                       #:nar-ttl (* 45 24 3600)
                                       #:motd %motd
diff --git a/hydra/berlin.scm b/hydra/berlin.scm
index 8d63a14..343e104 100644
--- a/hydra/berlin.scm
+++ b/hydra/berlin.scm
@@ -1,8 +1,8 @@
 ;; OS configuration for "berlin", the frontend of the compile farm
 ;; hosted at the MDC.
 
-(use-modules (gnu) (guix) (sysadmin services) (sysadmin people))
-(use-service-modules base databases monitoring networking admin shepherd)
+(use-modules (gnu) (guix) (sysadmin services) (sysadmin people) (sysadmin dns))
+(use-service-modules base databases dns monitoring networking admin shepherd)
 (use-package-modules admin certs emacs linux monitoring
                      ssh tls vim package-management
                      web wget ci rsync)
@@ -164,6 +164,21 @@ Happy hacking!\n"))
                               (tty "ttyS0")
                               (baud-rate "115200")))
 
+             ;; DNS
+             (service knot-service-type
+                      (knot-configuration
+                        (zones (list (knot-zone-configuration
+                                       (domain "guix.gnu.org")
+                                       (master '("bayfront-master"))
+                                       (acl '("notify-allow")))))
+                        (acls (list (knot-acl-configuration
+                                      (id "notify-allow")
+                                      (address (list bayfront-ip4))
+                                      (action '(notify)))))
+                        (remotes (list (knot-remote-configuration
+                                         (id "bayfront-master")
+                                         (address (list bayfront-ip4)))))))
+
              ;; Monitoring
              (service zabbix-agent-service-type)
              (service zabbix-server-service-type
diff --git a/hydra/modules/sysadmin/dns.scm b/hydra/modules/sysadmin/dns.scm
new file mode 100644
index 0000000..8ce93e6
--- /dev/null
+++ b/hydra/modules/sysadmin/dns.scm
@@ -0,0 +1,70 @@
+;;; GNU Guix system administration tools.
+;;;
+;;; Copyright © 2019 Julien Lepiller <julien@lepiller.eu>
+;;;
+;;; This program is free software: you can redistribute it and/or modify
+;;; it under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation, either version 3 of the License, or
+;;; (at your option) any later version.
+;;;
+;;; This program is distributed in the hope that it will be useful,
+;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (sysadmin dns)
+  #:use-module (gnu services knot)
+  #:export (guix.gnu.org-zone
+            berlin-ip4
+            bayfront-ip4))
+
+;;; Commentary:
+;;;
+;;; DNS configuration.
+;;;
+;;; For any change in the zone (an IP, a new record, ...), increment the
+;;; the serial in the zone configuration. This is very important for
+;;; changes to be taken into account.
+;;;
+;;; Remember some DNS rules: no other kind of record for a CNAME record.
+;;; Always associate a name that resolves to an A or an AAAA record
+;;; immediately (it cannot be a CNAME).  Same for MX.
+;;;
+;;; Remember that data is relative to the root of this zone when it
+;;; reference another domain name, unless it ends with a dot.
+;;;
+;;; Ex: "ns1.guix.gnu.org" actually means "ns1.guix.gnu.org.guix.gnu.org"
+;;; whereas "ns1.guix.gnu.org." means what it says.
+;;;
+;;; Code:
+
+;; Define some IP addresses for easier use later
+(define gnu.org-ip4 "209.51.188.148")
+(define gnu.org-ip6 "2001:470:142:3::a")
+(define hydra-ip4 "18.4.89.46")
+(define bayfront-ip4 "185.233.100.56")
+(define berlin-ip4 "141.80.181.40")
+
+(define-zone-entries guix.gnu.org.zone
+;; Name       TTL Class Type Data
+  ("@"        ""  "IN"  "A"      gnu.org-ip4)
+  ("@"        ""  "IN"  "AAAA"   gnu.org-ip6)
+  ("@"        ""  "IN"  "NS"     "ns1")
+  ("@"        ""  "IN"  "NS"     "ns2")
+  ("ns1"      ""  "IN"  "A"      bayfront-ip4)
+  ("ns2"      ""  "IN"  "A"      berlin-ip4)
+  ("hydra"    ""  "IN"  "A"      hydra-ip4)
+  ("berlin"   ""  "IN"  "A"      berlin-ip4)
+  ("bayfront" ""  "IN"  "A"      bayfront-ip4)
+  ("ci"       ""  "IN"  "CNAME"  "berlin"))
+
+(define guix.gnu.org-zone
+  (knot-zone-configuration
+    (domain "guix.gnu.org")
+    (zone (zone-file
+            (origin "guix.gnu.org")
+            (entries guix.gnu.org.zone)
+            (serial 1)))))
-- 
2.20.1

Re: DNS delegation

[Ludovic Courtès]

Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

> we've already discussed that multiple times, we'd like to have a DNS
> delegation for guix.gnu.org, so that we can manage the zone ourselves
> without having to rely too much on fsf sysadmins.
>
> Here is a patch (untested) that aims at doing that. I've configured
> bayfront and berlin to be DNS authoritative servers. bayfront is the
> master (it is the one that needs to be updated when a change happens in
> the zone), and berlin is set as slave (it will automatically follow
> changes in bayfront). I've enabled dnssec on bayfront, since it's the
> one that's going to sign the zone, and transfer signatures to its slave.

Cool, thanks for working on it!

> Currently the zone (in modules/sysadmin/dns.scm) is incomplete. What
> needs to be there?

I guess we’d need to have roughly the same entries as we currently have
on guix.info, so what you wrote is a good start and we can always adjust
later.

> From 331a85e469579c02a3fc338a6fb0bade3916c666 Mon Sep 17 00:00:00 2001
> From: Julien Lepiller <julien@lepiller.eu>
> Date: Mon, 4 Mar 2019 22:00:22 +0100
> Subject: [PATCH] hydra: Add dns services for guix.gnu.org.
>
> * hydra/bayfront.scm (services): Add knot-service.
> * hydra/berlin.scm (services): Add knot-service.
> * hydra/modules/sysadmin/dns.scm: New file.

So it looks like this does the work on the Guix side.

We now need to get the gnu.org admins to delegate to both bayfront and
berlin, is that correct?  Anything else we need to do?

Thank you!

Ludo’.

Re: DNS delegation

[Julien Lepiller]

Le 2019-03-13 16:00, Ludovic Courtès a écrit :
> Hi Julien,
> 
> Julien Lepiller <julien@lepiller.eu> skribis:
> 
>> we've already discussed that multiple times, we'd like to have a DNS
>> delegation for guix.gnu.org, so that we can manage the zone ourselves
>> without having to rely too much on fsf sysadmins.
>> 
>> Here is a patch (untested) that aims at doing that. I've configured
>> bayfront and berlin to be DNS authoritative servers. bayfront is the
>> master (it is the one that needs to be updated when a change happens 
>> in
>> the zone), and berlin is set as slave (it will automatically follow
>> changes in bayfront). I've enabled dnssec on bayfront, since it's the
>> one that's going to sign the zone, and transfer signatures to its 
>> slave.
> 
> Cool, thanks for working on it!
> 
>> Currently the zone (in modules/sysadmin/dns.scm) is incomplete. What
>> needs to be there?
> 
> I guess we’d need to have roughly the same entries as we currently have
> on guix.info, so what you wrote is a good start and we can always 
> adjust
> later.
> 
>> From 331a85e469579c02a3fc338a6fb0bade3916c666 Mon Sep 17 00:00:00 2001
>> From: Julien Lepiller <julien@lepiller.eu>
>> Date: Mon, 4 Mar 2019 22:00:22 +0100
>> Subject: [PATCH] hydra: Add dns services for guix.gnu.org.
>> 
>> * hydra/bayfront.scm (services): Add knot-service.
>> * hydra/berlin.scm (services): Add knot-service.
>> * hydra/modules/sysadmin/dns.scm: New file.
> 
> So it looks like this does the work on the Guix side.
> 
> We now need to get the gnu.org admins to delegate to both bayfront and
> berlin, is that correct?  Anything else we need to do?

I didn't think too much about it, but we need to host the website
(guix.gnu.org) somewhere and configure a vhost/server block accordingly,
unless gnu.org/software/guix stays the official website?

> 
> Thank you!
> 
> Ludo’.

Re: DNS delegation

[Ludovic Courtès]

Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

> Le 2019-03-13 16:00, Ludovic Courtès a écrit :
>> Hi Julien,
>>
>> Julien Lepiller <julien@lepiller.eu> skribis:
>>
>>> we've already discussed that multiple times, we'd like to have a DNS
>>> delegation for guix.gnu.org, so that we can manage the zone ourselves
>>> without having to rely too much on fsf sysadmins.
>>>
>>> Here is a patch (untested) that aims at doing that. I've configured
>>> bayfront and berlin to be DNS authoritative servers. bayfront is the
>>> master (it is the one that needs to be updated when a change
>>> happens in
>>> the zone), and berlin is set as slave (it will automatically follow
>>> changes in bayfront). I've enabled dnssec on bayfront, since it's the
>>> one that's going to sign the zone, and transfer signatures to its
>>> slave.
>>
>> Cool, thanks for working on it!
>>
>>> Currently the zone (in modules/sysadmin/dns.scm) is incomplete. What
>>> needs to be there?
>>
>> I guess we’d need to have roughly the same entries as we currently have
>> on guix.info, so what you wrote is a good start and we can always
>> adjust
>> later.
>>
>>> From 331a85e469579c02a3fc338a6fb0bade3916c666 Mon Sep 17 00:00:00 2001
>>> From: Julien Lepiller <julien@lepiller.eu>
>>> Date: Mon, 4 Mar 2019 22:00:22 +0100
>>> Subject: [PATCH] hydra: Add dns services for guix.gnu.org.
>>>
>>> * hydra/bayfront.scm (services): Add knot-service.
>>> * hydra/berlin.scm (services): Add knot-service.
>>> * hydra/modules/sysadmin/dns.scm: New file.
>>
>> So it looks like this does the work on the Guix side.
>>
>> We now need to get the gnu.org admins to delegate to both bayfront and
>> berlin, is that correct?  Anything else we need to do?
>
> I didn't think too much about it, but we need to host the website
> (guix.gnu.org) somewhere and configure a vhost/server block accordingly,

Yes, but that’s once DNS is appropriately set up.  I was asking about
what needs to be done to complete the DNS setup.

> unless gnu.org/software/guix stays the official website?

I think gnu.org/s/guix would redirect to guix.gnu.org, which would be
bayfront+berlin.  The issue that remains to be addressed in this context
is how to get Certbot to properly renew the certificate given that
guix.gnu.org points to two different machines.  IIRC you and others had
found a solution, but I don’t remember what it was and it needs to be
actually implemented.  :-)

Thoughts?

Ludo’.

Re: DNS delegation

[Tobias Geerinckx-Rice]

Ludo', Guix,

Ludovic Courtès wrote:
> I think gnu.org/s/guix would redirect to guix.gnu.org, which 
> would be
> bayfront+berlin.  The issue that remains to be addressed in this 
> context
> is how to get Certbot to properly renew the certificate given 
> that
> guix.gnu.org points to two different machines.  IIRC you and 
> others had
> found a solution, but I don’t remember what it was and it needs 
> to be
> actually implemented.  :-)

Was it… DNS-01 challenges?  That doesn't even care about IPs at 
all.

I could help set that up with Knot[0] — if Julien even needs help 
;-)

Kind regards,

T G-R

[0]: I also have a package for acme-dns[1] gathering dust, but 
IIRC we're using Knot already.
[1]: https://github.com/joohoi/acme-dns

Re: DNS delegation

[Julien Lepiller]

Le 2019-03-15 14:42, Tobias Geerinckx-Rice a écrit :
> Ludo', Guix,
> 
> Ludovic Courtès wrote:
>> I think gnu.org/s/guix would redirect to guix.gnu.org, which would be
>> bayfront+berlin.  The issue that remains to be addressed in this 
>> context
>> is how to get Certbot to properly renew the certificate given that
>> guix.gnu.org points to two different machines.  IIRC you and others 
>> had
>> found a solution, but I don’t remember what it was and it needs to be
>> actually implemented.  :-)
> 
> Was it… DNS-01 challenges?  That doesn't even care about IPs at all.

Does it mean we need to manually update the zone? How do you automate
that process?

> 
> I could help set that up with Knot[0] — if Julien even needs help ;-)
> 
> Kind regards,
> 
> T G-R
> 
> [0]: I also have a package for acme-dns[1] gathering dust, but IIRC
> we're using Knot already.
> [1]: https://github.com/joohoi/acme-dns

Re: DNS delegation

[Tobias Geerinckx-Rice]

Julien,

Julien Lepiller wrote:
>> Was it… DNS-01 challenges?  That doesn't even care about IPs at 
>> all.
>
> Does it mean we need to manually update the zone?

I was about to write ‘no, ha ha, imagine that’, but then I 
remembered that you're using the Guix service configuration 
wrappers which do hard-code the zone data in the system 
configuration :-/

You can always delegate a subdomain just for the ACME challenges, 
though, and have that statefully updated by a certbot hook.  I'm 
being vague because I don't know the exact names, but it's 
completely supported.

> How do you automate that process?

Me personally?  RFC-2136 (‘nsupdate’) dynamic updates, allowed 
only from localhost.  But I never use Guix's service configuration 
wrappers.

Kind regards,

T G-R