Project

General

Profile

Actions

tickets #173515

open

Refactor DNS zone transfers to replication

Added by crameleon 3 days ago. Updated 3 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
DNS
Target version:
-
Start date:
2024-11-30
Due date:
% Done:

0%

Estimated time:

Description

The current DNS setup consists of one "hidden master" PowerDNS authoritative server using a MySQL backend (local database) running on chip.i.o.o, and multiple secondaries across our infrastructure, which receive updates using the traditional zone transfer (NOTIFY then AXFR) mechanisms.
This has the significant drawback of only being able to update DNS record information when this hidden master is available.
A more modern approach is to use native replication in PowerDNS.

There are various solutions using the various database backends. For us, important is reliable replication across different locations, multi-master operation, and ideally low maintenance overhead.

Upon evaluation the best solution was found to be Lightning Stream.

This is officially endorsed by PowerDNS and makes use of the LMDB backend and S3 storage.

Further reading:

https://github.com/PowerDNS/lightningstream/
https://doc.powerdns.com/lightningstream/pdns-auth-installation/
https://doc.powerdns.com/authoritative/backends/lmdb.html
https://doc.powerdns.com/authoritative/migration.html#migrating-data-from-one-backend-to-another-backend

This depends on an improved internal S3 setup, and on switching the one remaining location, NUE, away from named to PowerDNS. Both of these are tracked in separate tickets.

For the migration process the only existing reference for a similar scenario as ours was an unanswered question on the mailing list, but I gathered the following steps:

  1. live-migrate the pdns instance on chip from MySQL to LMDB (link above)

  2. configure S3 bucket for Lightning Stream

  3. initial synchronization of data from pdns on chip into S3

    • either a) live-migrate the pdns instances on the secondary servers from SQLite to LMDB (might fail because currently autoprimary functionality is used, which is not supported in the LMDB backend)
  • or b) scrap the secondary SQLite databases and configure them with an empty LMDB database (this could be done in a separate, temporary, pdns instance on the same machines listening on a temporary port as to not disrupt the live setup - once the LMDB databases are populated from the master and the temporary instances were very validated to return the same data, the temporary instance can become the main)
  1. configure secondaries to sync with Lightning Stream

  2. verify all is working well (DNSSEC!), remove leftovers of SQLite and MySQL databases

  3. profit?


Related issues 2 (2 open0 closed)

Related to openSUSE admin - tickets #161846: Rework qsc-ns3New2024-06-05

Actions
Blocked by openSUSE admin - tickets #170167: New S3 deploymentNew2024-11-23

Actions
Actions #1

Updated by crameleon 3 days ago

Actions #2

Updated by crameleon 3 days ago

Actions #3

Updated by crameleon 3 days ago

  • Description updated (diff)
Actions #4

Updated by crameleon 3 days ago

  • Private changed from Yes to No
Actions #5

Updated by crameleon 3 days ago

  • Description updated (diff)
Actions

Also available in: Atom PDF