"External Secondary" Domain Support

We want to support PoweDNS's NATIVE domain type as an external domain entity. These are domains that should not be managed by out stack, but we need them for complementary services.

τη λειτουργία "external secondary" που θέλουμε να ενσωματώσουμε στο webdns. Η περίπτωση που εξετάζουμε είναι πελάτες του grnet (πχ ntua) που θέλουν να προσθέσουν τους ns0.grnet.gr, ns1.grnet.gr ως secondary nameservers για το koko.ntua.gr

+----------+           +-----------+
| PDNS vm  +---------->+ ODS vm    |
+----------+           +--+-----+--+
                          |     |
                          |     |
                          |     |
                +---------+     |
                |               |
                |               |
                |               |
           +----v---+       +---v----+
           |   ns0  |       |   ns1  |
           +--------+       +--------+

Το 'add secondary' που υποστηρίζεται αυτή τη στιγμή από το webdns το κρατάμε μεν αλλά δε μας κάνει:

θέλουμε ο μεν πελάτης να προσθέτει τα στοιχεία της secondary ζώνης (zone name, master IP) αλλά o powerdns από κάτω να μην κάνει AXFR. Αντίθετα θέλουμε το AXFR να το κάνουν οι ns0, ns1 που είναι οι public facing NS μας.

Ο τρόπος που θα κατεβάζουμε ζώνες στους ns0, ns1 (και τις primary) είναι με ένα μικρό python script (που θα γράψω) το οποίο θα χτυπάει στο API στο /private/zones, θα παρσάρει το json με όλες τις ζώνες και θα δημιουργεί το κατάλληλο configuration (πχ bind).

Effectively οι ns0, ns1 θα είναι πάντα slave για όλες τις ζώνες: για τις grnet ζώνες master θα έχουν τον ODS vm ενώ για τις third-party ζώνες θα έχουν master αυτόν του πελάτη (πχ ntua).

Η ιδέα λοιπόν είναι να γίνει expose στο /private/zones το 'type' και 'master' field του table domains οπότε να έχουμε κάτι τέτοιο:

> ➜  russell ~  curl -s https://webdns4.staging.grnet.gr/private/zones | jq .
> [
>   {
>     "id": 33,
>     "name": "koko.ntua.gr",
>     "group": "ntua",
>     "master": "147.102.1.1",
>     "type": "NATIVE"
>   },
>   {
>     "id": 17,
>     "name": "hidm-grnet.gr",
>     "group": "admin",
>     "master": "194.177.210.166",
>     "type": "MASTER"
>   }
> ]

το parsing script θα τσεκάρει το type. Για όσες ζώνες είναι master θα βάζει master το ODS vm, και όσες είναι native θα βάζει την master IP του πελάτη.

Όπως παρατηρείς και παραπάνω χρησιμοποιήσα το type 'NATIVE' του pdns και όχι 'SLAVE', ακριβώς για να μην κάνει AXFR ο pdns (έτσι λέει το documentation και φαίνεται να δουλεύει και στην πράξη).

Οπότε βασικά αυτό που λείπει από το UI είναι να μπορείς να δημιουργήσεις έναν τρίτο τύπο ζώνης, ας πούμε 'external secondary' (για να είναι σχετικά σαφές στους users και ο οποίος θα προσθέτει μια ζώνη ως NATIVE στη βάση. Προφανώς ο pdns και το web UI δε θα δουν ποτέ τα records της ζώνης, δε μας πολυνοιάζει αυτό. Απλά όταν κάνεις κλικ πάνω στο external secondary zone σου θα πρέπει να μη κάνει display αυτό https://users.noc.grnet.gr/~alexaf/Screenshot%20-%2011042016%20-%2005%3a45%3a48%20PM.png αλλά κάτι πιο σχετικό. Ίσως δεν χρειάζεται να είναι καν clickable, απλά να αναφέρει στο state ότι είναι external secondary.

Συνοψίζοντας, θέλουμε:

α) exposure των type και master στο API endpoint
β) προσθήκη 'external secondary' τύπου domain στην προσθήκη στο UI και σχετικές αλλαγές στο UI (non clickable domain blah)


> Subject: Re: εξέλιξη webdns4 + secondary DNS support
> Date: Sun, 12 Feb 2017 20:25:10 +0200
> From: Christos Trochalakis <yatiohi@ideopolis.gr>
> To: George Kargiotakis <kargig@noc.grnet.gr>, Alexandros Afentoulis <alexaf@noc.grnet.gr>
> 
> Καλησπέρα παιδιά, κάθισα επιτέλους κ' μάζεψα κάποιες σημειώσεις, ακολουθεί η
> καθυστερημένη απάντηση σχετικά με τις secondary ζώνες.

> Αυτή την στιγμή το WebDNS είναι ουσιαστικά ένα frontend για το PowerDNS MySQL
> backend (εκτός του dnssec), εφόσον θέλουμε μια σειρά από secondary ζώνες να
> περνάνε απευθείας στους primary DNS του ΕΔΕΤ (ns-pri, ns{0,1}) αυτό πρέπει να
> γίνει χωρίς να επηρεαστει ο PowerDNS κ' ο local bind του WebDNS.
> 
> Βλέπω 2 προσεγγίσεις, είτε οι ζώνες αυτές να μπουν στο zones table που ήδη
> υπάρχει, είτε να φτιαχτεί ένα δεύτερο table (secondary_zones) το οποίο
> λειτουργεί ανεξάρτητα.
> 
> # Προσθήκη στο `domains` table
> 
> Μπορεί να μπει μια τρίτη πιθανή τιμή στο `type` field, π.χ. SECONDARY εκτός
> από τις MASTER/SLAVE που καταλαβαίνει ο powerdns. Εδώ πρέπει να είναι σίγουρο
> ότι ο powerdns δεν "βλέπει" τα domains αυτά. Αυτό μπορεί να γίνει πειράζοντας
> τα διάφορα queries που γίνονται expose σαν configuration settings, με μια πρώτη
> ματιά το "info-zone-query" είναι ένα τέτοιο setting.
> 
> Όσο αφορά τις αλλαγές στο ίδιο το WebDNS, η ειδική κατάσταση του domain
> (type=CONDARY) πρέπει να ληφθεί υπόψην σε διάφορα σημεία:
> 
> ο Προβολή τέτοιων domain σε όλες τις περιπτώσεις (λίστες/φόρμες)
> ο Εξαίρεση από DNSSEC.
> o Εξαίρεση από αυτόματη δημιουργία SOA/NS record.
> o Προσαρμογή του API.
> ο Προσαρμογή των notifications.
> ο Expose secondary dns στο API endpoint για τους ns-pri,ns0,1.
> o Επίσης πολύ σημαντικό είναι το πως το σύστημα χειρίζεται αλλαγές από
>   secondary DNS στους άλλους δύο τύπους κ' ανάποδα (dangling rows στο records
>   tables, state machine, κτλ.
> 
> # Προσθήκη σε νέο `secondary_domains` table
> 
> Εδώ υπάρχει η σιγουριά ότι τα secondary domains δεν μπλέκονται με τα queries
> του powerdns. Το μεγάλο μειονέκτημα είναι κάποια λυμένα προβληματα πρέπει να
> ξαναυλοποιηθούν
> 
> ο Το permission system (owner group) πρέπει να υπάρχει κ' στον νέο πίνακα.
> o Νέα notifications για τον νέο πίνακα.
> ο Νέες φόρμες εισαγωγής / νέα views / update & destroy code.
> o Έλεγχος ότι τα domains δεν υπάρχουν στον domains πίνακα κ' αντίστροφα.
> ο Expose secondary dns στο API endpoint προς τους ns-pri,ns0,1.
> o new API endpoint (?)
> 
> # Τι είναι καλύτερο
> 
> Καμιά λύση δεν ειναι καθαρή, η πρώτη μπλέκει την κατάσταση στο πως χειριζόμαστε
> τα domains γενικά για μια περίπτωση δεν είναι καθόλου συχνή, κ' θα θέλει πάντα
> προσοχή σε σχέση με τα queries του powerdns. Η δεύτερη έχει περισσότερο κώδικα
> αλλά ξεχωρίζει εντελώς την κατάσταση με τα secondary domains κ' μπορει αργότερα
> να αφαιρεθεί πολύ εύκολα από το σύστημα αν δεν χρειάζεται πλέον η συγκεκριμένη
> υπηρεσία. Προσωπικά θα πήγαινα με την 2η λύση.
> 
>

grnet / webdns4

"External Secondary" Domain Support #13