nsd users - Aug 2005 - nsd and SERVFAIL

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

[in reply to nsd at walter.transip.nl, 14-8-2005]


        Uhm,

        after  doing a fresh install on a new box, we found that "nsdc
        update"  runs  successfully  even with zone files missing, and
        nsd   *does*  return  SERVFAIL  on  every  zone  that  is  not
        serviced... So this is perfect actually!

        So my previous question is irrelevant and can be ignored :)
        
        Kind regards,
        Walter Hop
        Transip BV


        
> 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



        


-- 
 Walter Hop <walter at lifeforms.nl> | Lifeforms |
http://www.lifeforms.nl/
 Dieses Schreiben wurde mit Hilfe einer Datenverarbeitungsanlage erstellt
 und bedarf daher keiner Unterschrift.