Zone hints for VPN environments

[Andreas Meile]

Hello Darcy and other posters

----- Original Message ----- 
From: "Darcy Kevin (FCA)" <kevin.darcy at fcagroup.com>
To: <bind-users at 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