nsd users - Jan 2020 - Seeking advice for deploying an anycast cluster

Thank you for taking the effort to type this up.   I think you've hit
on a solution here.   At least I believe you've got me thinking in the
right direction now.

On Fri, Jan 3, 2020 at 3:32 PM Niall O'Reilly <niall.oreilly at
ucd.ie> wrote:
> NSD is well capable of, and easily configured for, handling much
> greater fanout than two. In case the anycast cloud is really
> enormous, it may be sensible to use some intermediate distribution
> servers, as described below using the term "hidden slave".
It is.  38 servers and counting.  Spread out over the globe.
>
> > So for that to work, I'd need to somehow
> > cluster my NSD instances together or I'd need some sort of proxy
> > server that can listen for incoming NOTIFYs and then distribute them
> > to the rest of the constellation.
>
> Any of the authoritative name-server codes is designed to do exactly
> this kind of proxying. The old-fashioned terminology for a server
> which does only this, and which is not announced to the world in an
> NS record, is "hidden slave". Setting one of these up is
particularly
> easy to do with (perhaps another instance of) NSD. Other choices might
> be BIND (named), Knot, or PowerDNS.
I've been thinking about using PowerDNS anyways to front a web
interface for my customers.  Seems like the shortest path to market
considering it supports pgsql out of the box.
>
> An NSD-based hidden slave needs to refer to the upstream master
> in 'allow-notify' and 'request-xfr' configuration
directives and to
> refer to each dependent downstream server in 'notify' and
'provide-xfr'
> directives. Of course, the downstream servers must be configured
> correspondingly to accept NOTIFY and request a zone transfer when
> appropriate.
So I'm worried about nsd getting the right information from the right
source.   If I put my nsd instances in a "full mesh" so to speak,
where they are all XFR and NOTIFY each other, my "A" and "B"
PowerDNS
servers would still need to be the authoritative source for
information.  I'm assuming that's where the serial number of the zone
comes into play?   Highest provided serial number wins, right?

Subject: Re: [nsd-users] Seeking advice for deploying an anycast cluster Date:
Fri, Jan 03, 2020 at 09:22:46PM -0500 Quoting Daniel Corbe via nsd-users
(nsd-users at lists.nlnetlabs.nl):
> 
> So I'm worried about nsd getting the right information from the right
> source.   If I put my nsd instances in a "full mesh" so to speak,
> where they are all XFR and NOTIFY each other, my "A" and
"B" PowerDNS
> servers would still need to be the authoritative source for
> information.  I'm assuming that's where the serial number of the
zone
> comes into play?   Highest provided serial number wins, right?
Correct. 

Don't forget that you would be wise to include TSIG as well. Here, between
servers managed by the same entity, it is child's play. And being able
to prove that the AXFR is correct all the way is quite beneficial.

Further, you need a system to manage the "new zone deployment"
process,
as well as removal (but adding is more time-critical than removal). I've
used "dper.pl" from Kirei (https://github.com/kirei/dper) to automate
this for quite a few years now. No hickups. A new version that is Python
and YAML is in the works, of which I will have experience soon.

In summary: 

* every slave should fetch its zone from at least 2 masters, 

* serial governs which zone is loaded and served, 

* TSIG set up between masters and slaves, 

* NOTIFY (by virtue of "also-notify" in BIND and PowerDNS syntax)
makes
  things fast,

* Zone deployment is and was always supposed to be OOB, and needs to
  be handled. (NB: There with some frequency pops up suggestions to do
  in-band provisioning, and I THINK I've seen it on the feature list for
  some implementations, but no standard method has yet been devised.)


rgds, 
-- 
M?ns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
I hope I bought the right relish ... zzzzzzzzz ...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20200104/a7744ec4/attachment.bin>