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/_updown.netkey.in > > 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
