Log in


nsnotifyd-1.1: prompt DNS zone transfers for stealth secondaries

« previous entry | next entry »
2nd Jul 2015 | 16:19

nsnotifyd is my tiny DNS server that only handles DNS NOTIFY messages by running a command. (See my announcement of nsnotifyd and the nsnotifyd home page.)

At Cambridge we have a lot of stealth secondary name servers. We encourage admins who run resolvers to configure them in this way in order to resolve names in our private zones; it also reduces load on our central resolvers which used to be important. This is documented in our sample configuration for stealth nameservers on the CUDN.

The problem with this is that a stealth secondary can be slow to update its copy of a zone. It doesn't receive NOTIFY messages (because it is stealth) so it has to rely on the zone's SOA refresh and retry timing parameters. I have mitigated this somewhat by reducing our refresh timer from 4 hours to 30 minutes, but it might be nice to do better.

A similar problem came up in another scenario recently. I had a brief exchange with someone at JANET about DNS block lists and response policy zones in particular. RPZ block lists are distributed by standard zone transfers. If the RPZ users are stealth secondaries then they are not going to get updates in a very timely manner. (They might not be entirely stealth: RPZ vendors maintain ACLs listing their customers which they might also use for sending notifies.) JANET were concerned that if they provided an RPZ mirror it might exacerbate the staleness problem.

So I thought it might be reasonable to:

  • Analyze a BIND log to extract lists of zone transfer clients, which are presumably mostly stealth secondaries. (A little script called nsnotify-liststealth)
  • Write a tool called nsnotify-fanout to send notify messages to a list of targets.
  • And hook them up to nsnotifyd with a script called nsnotify2stealth.

The result is that you can just configure your authoritative name server to send NOTIFYs to nsnotifyd, and it will automatically NOTIFY all of your stealth secondaries as soon as the zone changes.

This seems to work pretty well, but there is a caveat!

You will now get a massive thundering herd of zone transfers as soon as a zone changes. Previously your stealth secondaries would have tended to spread their load over the SOA refresh period. Not any more!

The ISC has a helpful page on tuning BIND for high zone transfer volume which you should read if you want to use nsnotify2stealth.

| Leave a comment | Share

Comments {2}

Dr Plokta

from: drplokta
date: 2nd Jul 2015 18:04 (UTC)

Could you not slow down nsnotify-fanout by setting a pause of something like 600,000/<total number of servers to notify> milliseconds after each notification? Then you'll still update all your secondaries within ten minutes or so, but the herd is a bit less thundering.

Edited at 2015-07-02 06:05 pm (UTC)

Reply | Thread

Tony Finch

from: fanf
date: 2nd Jul 2015 19:09 (UTC)

Good suggestion - might be useful if you have huge numbers.

For my purposes I think I might only need a modest tweak to BIND's capacity knobs - our deployment is not very big. (And if other changes go ahead as I expect, we will move a lot of those stealth secondaries into forwarding resolvers instead, culling the herd.)

Reply | Parent | Thread