Bug #16232

Run a nameserver for the {amnesia,tails}.boum.org sub-zones

Added by intrigeri 2018-12-18 18:06:45 . Updated 2019-08-18 07:03:29 .

Status:
Resolved
Priority:
Elevated
Assignee:
intrigeri
Category:
Infrastructure
Target version:
Start date:
2018-12-18
Due date:
% Done:

100%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

… so our mirror admins can keep controlling it once boum.org’s NS has migrated to its new home.

Then:


Subtasks


Related issues

Blocks Tails - Feature #13284: Core work: Sysadmin (Adapt our infrastructure) Confirmed 2017-06-30
Blocked by Tails - Feature #15513: Switch to the puppetlabs/mysql module Resolved 2018-04-09

History

#1 Updated by intrigeri 2018-12-18 18:07:03

  • blocks Feature #13284: Core work: Sysadmin (Adapt our infrastructure) added

#2 Updated by intrigeri 2018-12-19 10:19:56

  • Subject changed from Run a nameserver for the amnesia.boum.org sub-zone to Run a nameserver for the {amnesia,tails}.boum.org sub-zones

While we’re at it, it’ll be super cheap to also manage tails.b.o sub-zone ourselves, so we can make changes there without asking A/I. Let me know if there’s a problem with that.

#3 Updated by intrigeri 2018-12-21 17:58:53

  • Description updated

#4 Updated by groente 2018-12-21 19:03:09

primary is up and running, we still need a secondary.

#5 Updated by intrigeri 2018-12-21 19:42:16

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 30

> * merge the 2 mirrors.git somehow

Done.

> * adapt mirror team scripts if needed
> * update mirror team doc

Done locally, will push once we are actually authoritative for amnesia.b.o.

#6 Updated by groente 2018-12-21 20:03:41

  • blocked by Feature #15513: Switch to the puppetlabs/mysql module added

#7 Updated by intrigeri 2018-12-22 13:49:52

  • Description updated

#8 Updated by intrigeri 2018-12-22 17:30:01

  • Description updated

NS switched, updated doc pushed.

#9 Updated by intrigeri 2018-12-29 10:41:22

  • Description updated

#10 Updated by intrigeri 2018-12-29 11:07:35

  • Description updated

#11 Updated by intrigeri 2018-12-29 13:19:59

  • Assignee changed from intrigeri to groente
  • QA Check set to Ready for QA

Monitoring added, see commits from today that reference this ticket’s ID.

#12 Updated by groente 2019-01-03 21:04:54

  • Priority changed from High to Elevated
  • QA Check changed from Ready for QA to Dev Needed

waiting for blockers before deploying a secondary

#13 Updated by intrigeri 2019-01-13 20:33:48

Is there a way we get a secondary without blocking on Feature #15513? See the DDoS thread on our sysadmin team list for details.

#14 Updated by groente 2019-01-13 21:23:46

intrigeri wrote:
> Is there a way we get a secondary without blocking on Feature #15513? See the DDoS thread on our sysadmin team list for details.

not really, replication has to be done through the mysql backend.

#15 Updated by intrigeri 2019-01-24 09:06:18

The upcoming DNS flag day came to my attention. According to https://dnsflagday.net/ our domain will still work after the flag day but a few EDNS compliance issues are raised: https://ednscomp.isc.org/ednscomp/3819fdd0ca. I don’t know enough about this topic to tell how bad the impact is and how to fix it.

#16 Updated by anonym 2019-01-30 11:59:37

  • Target version changed from Tails_3.12 to Tails_3.13

#17 Updated by intrigeri 2019-02-10 14:04:11

  • Description updated

Feature #15513 deployed, so with this blocker out of the way, here you may now:

  • review my changes (doc & monitoring) mentioned above
  • drop our temporary hacks i.e. hard reset the powerdns module to some upstream version (after checking that the re-enabled mysql-related code will indeed do what we want :)
  • set up the secondary (where?)

#18 Updated by geb 2019-02-13 10:41:26

Hi,

intrigeri wrote:
> The upcoming DNS flag day came to my attention. According to https://dnsflagday.net/ our domain will still work after the flag day but a few EDNS compliance issues are raised: https://ednscomp.isc.org/ednscomp/3819fdd0ca. I don’t know enough about this topic to tell how bad the impact is and how to fix it.

I also gave a look, and pinged a friend about that. His response let me think that its a bug in the test tool itself, and that there is no problem in the Tails nameserver :

> Strange. Unlike what the above URL says, there is no SOA:
>
> % dig +nocookie +norec +noad +edns=1 +noednsneg soa tails.boum.org 198.252.153.59 > > <<>> DiG 9.11.5-P1-1-Debian <<>> +nocookie +norec +noad +edns=1 +noednsneg soa tails.boum.org 198.252.153.59
> ;; global options: +cmd
> ;; Got answer:
> ;; >HEADER<< opcode: QUERY, status: BADVERS, id: 47257
> ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1680
> ;; QUESTION SECTION:
> ;tails.boum.org. IN SOA
>
> ;; Query time: 134 msec
> ;; SERVER: 198.252.153.59#53(198.252.153.59)
> ;; WHEN: Mon Feb 04 09:02:09 UTC 2019
> ;; MSG SIZE rcvd: 43

The “problem” also exists for other powerdns installs, for instance powerdns.net https://ednscomp.isc.org/ednscomp/56b28c9733. I’ll try to report the issue asap.

#19 Updated by geb 2019-02-13 11:09:39

geb wrote:
> intrigeri wrote:
> > The upcoming DNS flag day came to my attention. According to https://dnsflagday.net/ our domain will still work after the flag day but a few EDNS compliance issues are raised: https://ednscomp.isc.org/ednscomp/3819fdd0ca. I don’t know enough about this topic to tell how bad the impact is and how to fix it.
>
> I also gave a look, and pinged a friend about that. His response let me think that its a bug in the test tool itself, and that there is no problem in the Tails nameserver
> […]
> The “problem” also exists for other powerdns installs, for instance powerdns.net https://ednscomp.isc.org/ednscomp/56b28c9733. I’ll try to report the issue asap.

Done: https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing/issues/34

#20 Updated by geb 2019-02-13 16:00:09

geb wrote:
> geb wrote:
> > intrigeri wrote:
> > > The upcoming DNS flag day came to my attention. According to https://dnsflagday.net/ our domain will still work after the flag day but a few EDNS compliance issues are raised: https://ednscomp.isc.org/ednscomp/3819fdd0ca. I don’t know enough about this topic to tell how bad the impact is and how to fix it.
> >
> > I also gave a look, and pinged a friend about that. His response let me think that its a bug in the test tool itself, and that there is no problem in the Tails nameserver
> > […]
> > The “problem” also exists for other powerdns installs, for instance powerdns.net https://ednscomp.isc.org/ednscomp/56b28c9733. I’ll try to report the issue asap.
>
> Done: https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing/issues/34

Apparently,

#21 Updated by groente 2019-02-13 16:08:26

  • Assignee changed from groente to intrigeri
  • QA Check changed from Dev Needed to Info Needed

we haven’t really decided where to deploy the secondary yet. ecours seems to me the most sensible place, what do you think?

#22 Updated by intrigeri 2019-02-13 16:51:26

  • Assignee changed from intrigeri to groente
  • QA Check changed from Info Needed to Dev Needed

> we haven’t really decided where to deploy the secondary yet. ecours seems to me the most sensible place, what do you think?

In terms of network & geographical diversity, sure, among the systems we’re already running it’s the most sensible option.

Regarding security, I don’t remember if we’ve made any special choice in ecours’ setup that would make it unsuitable for hosting our DNS; putting aside “running a PHP webapp” exposed to the Internet, I think it’s OK. One should check that we didn’t give icinga2/icingaweb2 full control over MariaDB there.

Finally, regarding resources:

  • I assume DNS won’t take much CPU, even with a MySQL backend.
  • We already run MariaDB.
  • There’s a little bit of RAM left, not much when Puppet is running though. Might be a bit tight.
  • There’s tons of free space in the PV.
  • We need to check what’s the upstream firewalling setup. E.g. we’re not allowed to make outgoing DNS queries. Perhaps we need to get an exception to accept incoming DNS queries.

#23 Updated by CyrilBrulebois 2019-03-20 14:34:11

  • Target version changed from Tails_3.13 to Tails_3.14

#24 Updated by CyrilBrulebois 2019-05-23 21:23:29

  • Target version changed from Tails_3.14 to Tails_3.15

#25 Updated by CyrilBrulebois 2019-07-10 10:34:11

  • Target version changed from Tails_3.15 to Tails_3.16

#26 Updated by groente 2019-08-16 13:45:53

  • Status changed from In Progress to Needs Validation
  • % Done changed from 30 to 70

so, we now have a new virtual machine named teels, hosted in amsterdam, running secondary dns \o/

on our side, everything seems ready, NS records are pointing to both our nameservers, etc. if all goes well, A/I should add this new machine in the boum.org zone this evening and then it’s running production.

#27 Updated by groente 2019-08-16 13:46:19

  • Assignee changed from groente to Sysadmins

#28 Updated by groente 2019-08-16 19:22:15

  • % Done changed from 70 to 80

our secondary dns is now in production. i also removed some inconsistencies between A/I’s delegation and our own zones and sanitised the SOA records.

#29 Updated by intrigeri 2019-08-17 14:29:04

  • Status changed from Needs Validation to In Progress
  • Assignee changed from Sysadmins to groente
  • % Done changed from 80 to 90

Hi @groente! Code review passes. I’ve tested various simple queries to both nameservers and it looks good. I did not test making changes on the primary and checking whether the secondary picks them up.

There are a couple last things to do before we can close this ticket, see Bug #16232#note-17 so I’m giving you this ticket back.

#30 Updated by groente 2019-08-17 16:26:01

  • Status changed from In Progress to Needs Validation
  • Assignee changed from groente to Sysadmins

intrigeri wrote:
> Hi @groente! Code review passes. I’ve tested various simple queries to both nameservers and it looks good. I did not test making changes on the primary and checking whether the secondary picks them up.

Cool, I’ve tested the sql replication, that seems to work fine.

> There are a couple last things to do before we can close this ticket, see Bug #16232#note-17 so I’m giving you this ticket back.

Reviewed the docs, they’re still looking good.

The monitoring code looks good aswell, I did change the default SOA name to match our actual record, but this seems to be a purely aesthetical thing.

The puppet-powerdns submodule is now switched to upstream: https://github.com/sensson/puppet-powerdns.git

I guess we’re ready to close?

#31 Updated by intrigeri 2019-08-17 17:26:10

  • Assignee changed from Sysadmins to intrigeri

> The puppet-powerdns submodule is now switched to upstream: https://github.com/sensson/puppet-powerdns.git
> I guess we’re ready to close?

I’ll review this change and expect I’ll then be happy to close this ticket :)))

#32 Updated by intrigeri 2019-08-18 07:03:29

  • Status changed from Needs Validation to Resolved
  • % Done changed from 90 to 100

LGTM!