connection dropped after trying to add NS records

[Kevin Darcy]

Smith, Earl (Exchange) wrote:

>I'm running bind9.3.1 on a Sun v440 running Solaris 8.  All zones are
>dynamic (DDNS).
>I'm doing a bunch of updates by hand.  All of a sudden the connection
>seems to have been dropped, right after adding NS records pointing to
>our Global Load Balancer.
>Anybody ever see this and know the cause and how to fix?
>
>Example follows.
>
>pwdnsbear1# nsupdate
>  
>
>>server pwdnsbear1
>>
>>update delete a.is.bear.com a 172.27.60.97
>>
>>update add a.is.bear.com 3600 IN a 172.27.60.97
>>
>>update add b.is.bear.com 3600 IN a 172.24.64.203
>>
>>update add c.is.bear.com. 3600 IN a 172.24.64.204
>>
>>send
>>
>>update add d.is.bear.com. 3600 IN ns gss1.is.bear.com.
>>
>>update add d.is.bear.com. 3600 IN ns gss2.is.bear.com.
>>
>>    
>>
>; Communication with 147.107.215.18#53 failed: timed out
>could not talk to specified name server
>pwdnsbear1#
>
Use nsupdate's "zone" directive when adding NS records above a zone cut. 
I suspect what's happening here is that nsupdate is generating an SOA 
query to discern the closest-enclosing zone of the Dynamic Update 
transaction, you're forwarding the SOA query, it's going to the 
load-balancer and timing out because the load-balancer doesn't know what 
to do with it. "zone" obviates the SOA query and tells nsupdate 
explicitly that the NS records belong in the parent zone, not the child.

Note that if this is truly a Cisco GSS device, you can configure it to 
"proxy" queries with non-A QTYPEs, so that it won't just time out if it 
gets one. Set up a "shadow" version of the relevant zone(s) with SOA, 
NS, MX records, etc. and point the GSSes to it. Just make sure this 
"shadow" version of the zone isn't in the resolution path for anything 
but the GSSes themselves (I ended up having to define a special view for 
the GSSes to prevent any interference).

- Kevin