Hello Darcy and other posters
----- Original Message -----
From: "Darcy Kevin (FCA)" <kevin.da...@fcagroup.com>
To: <bind-users@lists.isc.org>
Sent: Tuesday, February 16, 2016 1:42 AM
Subject: RE: Zone hints for VPN environments
Note that there are additional considerations if there are any descendant
(child, grandchild, etc.) zones of intra.example.net.
Thanks for all your comments. I already have recognized that this is a more
complex problem that I thought first.
Another poster suggested "type slave", i.e. replicating the zone contents
via the
standards-defined AXFR/IXFR features of the protocol. While I'm generally
a big fan
of zone replication, between different legal entities there is often a
concern about
unintentional information disclosure.
This is a good point but: Some VPN links are not always connected (the
customer must explicitely activate it when a support operation is needed and
disconnect when finished) so my named would produce a lot error log (and
even loose all cached information after 14 days) during the closed VPN
phase. Additionally in case of deeper DNS zones, for example
departx.intra.example.net, addition slave configuration on my named and
always keeping updated manually the zone list is needed.
This is the reason why I prefer a solution to say to my named: "When
resolving something in intra.example.net and deeper, use 10.55.2.3. For all
other domains, use 192.0.2.44 and/or 198.51.100.2 or even the public root
hints." => It does not hurt when 10.55.2.3 is sometimes not reachable
because outside a VPN session, I don't need to resolve any host names inside
intra.example.net into their IP addresses when no such service operation is
running.
Andreas
--
"127.0.0.1 was ist das? Ich kenne nur ::1!" - www.swissipv6council.ch
_______________________________________________
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
