zone delegation/forwarding in a non-recursive view

Yiorgos Stamoulis yiorgos-lists at stamoulis.eu
Sat Oct 26 12:24:27 UTC 2013


Hi Kevin, Mark & Kevin,

thank you for your questions that pointed me to the right track.

A quick summary:

I did my testing in a dev server (let's say with IP address 
123.123.123.10) , that is serving the same zones as the live server.  I 
added to the zone file, lets call it example.com, the following:

$ORIGIN subdn
@     IN    NS   ns
ns    IN    A    123.123.123.20

the server at running at 123.123.123.20 was configured to as 
authoritative for zone subdn.example.com.

 From a client in the internal view:

dig xxx.subdn.example.com @123.123.123.10
dig xxx.subdn.example.com @123.123.123.20

would work OK

 From a client in the external view:

dig xxx.subdn.example.com @123.123.123.10

would fail with 'recursion requested but not available'.

I was testing with dig @123.123.123.10 as it is a dev server not 
advertised as handling example.com in the dns hierarchy proper.

After applying the same settings on the live servers dig A 
xxx.subdn.example.com +trace shows delegation now works OK, and after 
allowing negative caches to expire host xxx.subdn.example.com also gives 
the right answer.

Lessons learned:

  * If you are going to have a dev server, have a dev domain too (and
    not a shadow of the live domain), with working delegation from the
    root servers down, and do not try to cut corners with dig @dev-server
  * In dev servers, use really short TTLs!
  * delegation & forwarding are VERY different and you should be very
    clear to which one is ppropriate.  A workaround is NOT a solution.

Thanx again

Y










-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20131026/0ab2d802/attachment.html>


More information about the bind-users mailing list