Am 12.04.2014 17:11, schrieb Paul Wouters:
On Sat, 12 Apr 2014, Reindl Harald wrote:
"we" should not do anything - because "we" don't have a clue about the network of the enduser
We know and handle a lot more than you think already using unbound with dnssec-trigger and VPNs. Why don't you give it a shot and give us some feedback on how it works for you on your laptop?
because i stopped to use laptops years ago? because i have way too complex dns setups for such magic? because i don't touch NM in that life?
i speak in that thread as one who understands the pain of playing with DNS and what happens if assumtions are made wrong
if the roadrunner has the VPN client directly on his machine, well then he needs to make a decision:
They needs to make no decision, it has been automated already:
https://github.com/libreswan/libreswan/blob/master/programs/_updown.netkey/_...
if [ -n "$(pidof unbound)" ]; then echo "updating local nameserver for ${PLUTO_PEER_DOMAIN_INFO} with ${PLUTO_PEER_DNS_INFO}" /usr/sbin/unbound-control forward_add ${PLUTO_PEER_DOMAIN_INFO} ${PLUTO_PEER_DNS_INFO} /usr/sbin/unbound-control flush_zone ${PLUTO_PEER_DOMAIN_INFO} /usr/sbin/unbound-control flush_requestlist return 0 fi
and if you cross my street with a users machine give me a single button to disable that because you break my setups with that - no i can't explain internal infrastructure in the public but there has to be no local cache in my way
if a co-worker asks for a dns-record, tried to call the site already you have no business to have a negative cache on the client while all 4 internal nameservers where two are already caching-servers for external responses and used as forwarder for non-auth zones have already the answer
DNS1: cache DNS2: cache DNS3: auth for 600 zones DNS4: auth for 600 zones
users asking DNS1 and DNS2 they are doing recursion
DNS3 and DNS4 are for public access from the internet to resolve customer domains