nsd and SERVFAIL

[Walter Hop]

Hello all,

after  yet another night of BIND upgrades and waking up to BIND INSIST
failures  (sigh),  I'm  tempted  to  move  to  NSD again, but I have a
question left.

I  generate nsd.zones and the zonefiles with a script. We have a setup
with  around  20K zones where around 2K zones are slaved from customer
servers.

Because  of  the  number  of slave zones, inevitably there is always a
large  number  of  them  which  can't  be  AXFR-ed because of customer
downtime, firewall misconfigurations, incorrect ACL's, et cetera.

Now,  BIND  handles this in a way that for broken masters it returns a
SERVFAIL  response.  This  is useful to me because clients will get an
informative  error and ultimately reach the customer's own master. But
with  NSD  it  seems  that  I  only  have  the  option of not becoming
authoritative for this zone at all. Do I understand this correctly?

Is  there  a way to get a SERVFAIL behavior with NSD? I am thinking of
the following:
- writing 'failed' zone files to seed the slave zones
- then running "nsdc update" which will try to retrieve the real zones
- "nsdc rebuild" would always succeed and I won't have to remove any
  zones from the nsd.zones file

I  am  guessing this would require patching of zonec to have some kind
of  'failed zone' token, and nsd to return SERVFAIL when it finds this
token  in  the  db.  We are already looking at the source, but perhaps
there a simpler way that we have missed?

I  would rather not remove any broken zone files from my configuration
automatically,  because  this  sounds to me like it has more potential
for  nasty  breakage:  I'd  have to rewrite the nsd.zones file to cull
broken  masters, and I'm afraid becoming non-authoritative could break
lookups and generate a lot of customer confusion.

Any input would be appreciated :)

Kind regards,
Walter Hop
Transip BV


-- 
  Transip BV | http://www.transip.nl/
  Hoogwaardige Innovatie | Aangename Zekerheid