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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
