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.netke...
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