default local DNS caching name server: test it right now and report bugs

[Petr Spacek]

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