middleware: slaving zones about coredns HOT 7 CLOSED

Let's take an example from my current setup:

zone "rikribbers.nl" {
    type slave;
    masters { 92.63.172.25; 2a00:f10:121:400:252b:5421:6ba3:3d10; };
    file "/var/lib/bind/rikribbers.nl";
    zone-statistics yes;
};

So, this means a couple of things

1. be able to receive and act on incoming notifies
2. requery the master at intervals specified in the SOA parmeters
3. dropping the zone; SERVFAIL when expire is expired
4. ability to configure masters
5. where to put the zone (use assets path by default? ~/.caddy)

Looking at https://www.knot-dns.cz/docs/1.6/html/configuration.html, need idea: no concept of slave zone (per se). It is just a keyword in the configuration. Rought idea for config syntax (btw: supermaster is also a cool idea).

rikribbers.nl {
    transfer db.rikribbers.nl master_ip/name...
}

transfer itself will have some more options

transfer {
    file db.rikribbers.nl
    from master_ip/names...
    <options 'n stuff>
}

from coredns.

transfer can work, it only need to point to a zonefile, or should we use some kind of abstraction that it allows to query other middleware what their zone looks like. The latter is nice, but I have no idea how this will look. As a first pass, using a file as an intermediate way of communicating should suffice.

from coredns.

otoh, slaving a zone (i.e. responding to axfr/ixfr) is highly middleware specific; not sure if this can be done as a generic middleware and should just be done in the (e.g.) file middleware. It boils down to sending notifies and then responding to transfer requests.

slaving zones might be diff., but (as said) not sure yet.

from coredns.

This will be an option in the file middleware.

If we ever get something that will read from a database, we'll revisit. Or maybe the whole read from thing must be abstracted and shared between middlewares?

from coredns.

Slaving zones is highly middleware specific and needs a better abstraction. For example a SOA serial strategy needs more thought before supporting more than 100 zone changes a day. Here is some light reading on that problem: https://lists.dns-oarc.net/pipermail/dns-operations/2016-March/014623.html

from coredns.

LOL ;-)

from coredns.

See the secondary middleware - not perfect yet, but working. Closing for now. Once all this stuff is functional we'll do another passover and make it perfect.

from coredns.