On 12.4.2014 17:25, Reindl Harald wrote:
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
It seems that this thread contains a lot of hand-waving about problems which
can theoretically happen.
I would like to move the discussion to more constructive stage - get your
hands dirty! :-)
Instructions for testing on Fedora 20+ are available on:
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test
Please, run dnssec-trigger and let exclamations like "It can't possibly work!"
apart. Send constructive bug reports instead.
E.g.
- My network has static configuration XYZ in /etc/sysconfig/... and it doesn't
work. "unbound-control list_forwards" shows empty list.
- I can't access my corporate mail server when I'm connected to VPN.
journalctl -f -u unbound.service shows this:
unbound[1062]: [1062:0] info: validation failure <mail.corp.com. A IN>: no
keys have a DS with algorithm RSASHA1 from 192.168.2.1 for key
dnssec-failed.org. while building chain of trust
etc. etc.
We need real data.
Thank you very much for your attention.
--
Petr^2 Spacek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
