Bug #16232
Run a nameserver for the {amnesia,tails}.boum.org sub-zones
100%
Description
… so our mirror admins can keep controlling it once boum.org’s NS has migrated to its new home.
Then:
merge the 2mirrors.git
somehowadapt mirror team scripts if neededupdate mirror team docadd monitoring of this NS- -document on https://tails.boum.org/contribute/working_together/roles/sysadmins/- (
Bug #16254)
Subtasks
Related issues
Blocks Tails - Feature #13284: Core work: Sysadmin (Adapt our infrastructure) | Confirmed | 2017-06-30 | |
Blocked by Tails - |
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
#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
- 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,
- The test tools is right, their is a problem with powerdns 4.0, see,
- The problem is not considered as critical: https://www.isc.org/blogs/dns-flag-day/ “On the authoritative side, PowerDNS 4.1 is fully compliant; 4.0 has some corner cases that ednscomp notices but that are not a problem in practice – disabling caching removes those edge cases.”
- Their is a debian bug about the issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918661
- Not sure disabling caching worth it, as (I guess) it may hurt performances.
#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!