Re: default local DNS caching name server
On Sun, 13 Jul 2014, quickbooks office wrote: DNS over SSL does NOT work - I get no connectivity whatsoever after following the below steps. Tracking bug at https://bugzilla.redhat.com/show_bug.cgi?id=1119050 Can you please tell me what am I doing wrong? There seems to be some regression with unbound causing packets to go out on port 53 instead of 443 when enabling ssl-upstream. I'm investigating and will run a bisect. btw to test unbound without using firewall rules of dnssec-trigger, use: sudo unbound-control forward_add . 80.239.156.220 sudo unbound-control set_option ssl-upstream: yes This is basically what dnssec-trigger does in the fallback case. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
DNS over SSL does NOT work - I get no connectivity whatsoever after following the below steps. Tracking bug at https://bugzilla.redhat.com/show_bug.cgi?id=1119050 Can you please tell me what am I doing wrong? @ https://fedoraproject.org/wiki/Test_Day:2012-12-11_Network_Manager_and_DNSSEC it says to do: sudo yum install dnssec-trigger sudo systemctl enable dnssec-triggerd.service sudo systemctl enable unbound.service sudo reboot Then to get DNS over SSL @ https://fedoraproject.org/wiki/QA:Testcase_DNS-over-SSL it says to do: sudo iptables -A OUTPUT -o lo -j ACCEPT sudo iptables -A OUTPUT -p tcp --dport 53 -j DROP sudo iptables -A OUTPUT -p udp --dport 53 -j DROP Then we are supposed to click on re-probe. And now there is no connectivity. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On 25.4.2014 18:19, Simo Sorce wrote: On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote: On Thu, 10 Apr 2014 10:41:54 -0400 Chuck Anderson wrote: [...] We need an independent, system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to solve this fundamental design problem with how name resolution works on a Linux system. Windows has had a default system-wide DNS cache for over a decade. It is about time that Linux catches up. I observe you pointedly ignore the existence of nscd (which does not require any changes to resolv.conf). Why is that? nscd is ... bad Main goal is to have local DNSSEC-validating resolver. -- Petr^2 Spacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote: > On Thu, 10 Apr 2014 10:41:54 -0400 > Chuck Anderson wrote: > > > [...] We need an independent, > > system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to > > solve this fundamental design problem with how name resolution works > > on a Linux system. Windows has had a default system-wide DNS cache > > for over a decade. It is about time that Linux catches up. > > I observe you pointedly ignore the existence of nscd (which does not > require any changes to resolv.conf). Why is that? nscd is ... bad Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Thu, 10 Apr 2014 10:41:54 -0400 Chuck Anderson wrote: > [...] We need an independent, > system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to > solve this fundamental design problem with how name resolution works > on a Linux system. Windows has had a default system-wide DNS cache > for over a decade. It is about time that Linux catches up. I observe you pointedly ignore the existence of nscd (which does not require any changes to resolv.conf). Why is that? -- Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server: test it right now and report bugs
Hi, > On Tuesday, 15 April 2014 4:02 PM, Petr Spacek wrote: > We need real data. Please see -> https://www.piratepad.ca/p/dnssec-requisites-configurations I've collected the major functionalities people wish to have with a default DNS resolver along with couple of 'unbound' configurations that I tried. It'll greatly help if others could also list their configuration details on the same page. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server: test it right now and report bugs
Hello Petr, > On Tuesday, 15 April 2014 4:02 PM, Petr Spacek wrote: > 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. > > We need real data. Excellent! Thank you so much for doing this Petr. I was going to do the same. Summarise the discussion so far, list down the problem areas and invite users to report their problems. Having real first hand data and bug reports would be extremely effective in developing the NM plugins and integration with NM. I'll try both the configuration on my machine. Thank you! :) --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server: test it right now and report bugs
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 : 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, 14 Apr 2014, Juan Orti Alcaine wrote: One thing I would like to note is that in machines which don't have a hardware clock, I had problems starting bind and unbound, because the date was back to 1970 in each boot, so the root dns key was not yet valid and there were no valid dns resolvers to update time by ntp. I had to hardcode some ntp servers IP addresses to perform the ntp queries at boot time. This was using the OpenWrt distro in a mips router, I don't know if we can face this kind of problem in ARM machines. I guess all x86 have hardware clock, doesn't they? That's a problem we are aware of. tlsdate is one method, but I believe the openwrt people now also do some other things. Possibly saving the time on shutdown so you have a reasonable time on startup. For DNSSEC, we found that you need accurancy within a couple of hours because some RRSIGs in the path to .org (for ntp.pool.org) were pretty short. But I think adding a few ntp servers by IP address could be good for the standard ntp config as well - provided there are IPs that can be used for that in the pool. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, Apr 14, 2014 at 9:06 AM, Dan Williams wrote: > On Mon, 2014-04-14 at 12:00 -0400, Paul Wouters wrote: >> On Mon, 14 Apr 2014, Dan Williams wrote: >> >> > But another scenario I've seen: older Netgear routers which intercept >> > "www.routerlogin.net" as the setup page. The instructions literally >> > are: >> > >> > 1) connect your computer to the router with a cable >> > 2) go to www.routerlogin.net >> > 3) follow the setup guide instructions >> > >> > Any idea how dnssec-trigger + unbound would handle this? Since it's >> > router setup, maybe spawning the whole new window for the "portal" would >> > work, but you'd want to make sure the window didn't go away or DNS >> > didn't change until the user was done setting up the router. >> >> I don't know what they do when you query for anything else. If there is >> no hotspot redirection on port 80/443 and their DNS server works >> properly, and your wifi was secure, you would then get their forward >> and the above would work. If it is an open wifi, we would not install > > Since the user is setting things up, they can pick whether it's open or > protected wifi. We don't control that. > >> the forward and you would not get there. but in the current setup, you >> can pick "hotspot login" mode and it puts their DNS in place, and than >> you will reach it. Note that manual hotspot login sessions require you > > Ok, that could be a problem. This is a user setting up wifi on a router > they just bought, so it has no upstream connection yet, is not yet > configured at all, and they are just following the directions in the > printed brochure they got with the router. Which obviously won't say > anything about "hotspot login" mode. > > Also, this is the procedure you follow if you reset the router to > factory defaults, which support people sometimes tell you to do. So > we'd run into the issue if/when the user contacted Netgear technical > support too. If you want to get really fancy, you could try to detect a state in which there is no connection to the internet, the router has an address 192.168.*.1, and the router is listening on TCP port 80, and suggest an alternate "you are connected to a possibly unconfigured router" mode. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, 14 Apr 2014, Dan Williams wrote: Ok, that could be a problem. This is a user setting up wifi on a router they just bought, so it has no upstream connection yet, is not yet configured at all, and they are just following the directions in the printed brochure they got with the router. Which obviously won't say anything about "hotspot login" mode. But dnssec-trigger detects the hotspot detection portal page didn't return the expected page content of "OK" and will suggest to the user to go into hotspot signon mode. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Tue, 15 Apr 2014, William Brown wrote: How do you setup DNS over TLS? Unbound has this capability already build in. unbound-control activates via (currently via dnssec-triggerd, in the future via NM) using the keywords tcp-upstream or ssl-upstream. I meant for say bind, but okay. bind does not support this. For a detailed list you will have to check the source code. But it includes thing like DNSSEC records, proper wildcard NSEC(3) records, CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older versions of common DNS software. Cases the IETF actually experienced in the wild. IE, If I have an out of box bind9 setup with a few zones, or even 100s of zones, these cases should never be triggered. I would hate to see the "dodgy DNS" check giving a false positive on networks that are actually sane ... Such checks need to be conservative in their triggers IMO. Correct. It only happens for bind4/bind8 or broken old bind9s, djbdns/cache, but mostly because of 5 year old dnsmasq versions embedded in the platforms as "dns proxy". Even if we ignore the TTL mangling, the first issue of incorrect cached zone data moving between networks is a real world issue IMO. As previously mention, split view business networks. I believe you have said this is solved by flushing "." forwarder between networks that are "secure". Correct. If an ISP starts modifying DNS content, it is simply an attack. You have no trust relationship with them. The reason I ask these are documented, is so that when other network admins (like myself) come along, you have already had the argument and provided the justification and detailed explanations of these "edge cases". Understood. "suboptimal route". Your workaround will actually be detrimental to the user experience. Note, I'm trying to optimise that path too, see: http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query-00 These two statements really seem to contradict. On one hand you say that moving between secure networks, the "." forwarder gets flushed. But then you say the whole point is that it isn't flushed! The number of flushes should be limited as much as possible. It is only to accomdate certain networks that we flush the cache. Our preference is to never flush. But we accept sometimes it cannot be avoided to support certain type of DNS deployments. On my 3g tether, and work, both would be secure wifi, so according to this both flush (Which really, I like :) ) But according to what you are saying they shouldn't do that, but they do? The price we have to pay to support some kind of setups. We can also add an option that tells us to not flush certain (secure) networks because we know there is no special casing there. Those are tunings we can do later. Really, it seems like the only time the cache *won't* flush is when I move from a secure wifi to an insecure wifi. What happens when I move from the insecure wifi back? I would like to argue that given not all domains have DNSSEC yet, you can't "trust" the records from the insecure wifi, so at the least on insecure wifi interface down, you should flush the non-dnssec cached records. Whether the network is "secure" or "insecure" only has an effect on the forwarder state, and thus potentially certain domains handled by that forwarder. DNSSEC validation is not skipped in those cases, so data can still be trusted. Non-DNSSEC domains are always vulnerable to a MITM. Since they can just sign their domains, I don't feel personally that we need to go out of our ways to accomodate those insecure setups. If people will differently, again we could tune and make a toggle. Which collecting this seems to mean (Current functional state): Secure to secure network -> Flush "." cache. Secure to insecure network -> Keep cache Insecure to Insecure network -> Keep cache Insecure to secure network -> Keep cache. I think in the perfect world, assuming that insecure networks are insecure shouldn't it be? Secure to secure network -> Flush "." cache. Secure to insecure network -> Keep cache Insecure to insecure network -> Keep DNSSEC cache only. Insecure to secure network -> Keep DNSSEC cache only. I'll think about these a little more. Note that "keep DNSSEC cache only" is currently not an option implemented by unbound. The only records you can really guarantee as being the same on all network views are ones signed by DNSSEC. Not really, you can have differently signed zones for the same name for internal and external view. Hopefully with at least the same DNSKEY, but even that could be different. It would require a manual configuration though of files in /etc/unbound/*.d/ Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, 2014-04-14 at 12:00 -0400, Paul Wouters wrote: > On Mon, 14 Apr 2014, Dan Williams wrote: > > > But another scenario I've seen: older Netgear routers which intercept > > "www.routerlogin.net" as the setup page. The instructions literally > > are: > > > > 1) connect your computer to the router with a cable > > 2) go to www.routerlogin.net > > 3) follow the setup guide instructions > > > > Any idea how dnssec-trigger + unbound would handle this? Since it's > > router setup, maybe spawning the whole new window for the "portal" would > > work, but you'd want to make sure the window didn't go away or DNS > > didn't change until the user was done setting up the router. > > I don't know what they do when you query for anything else. If there is > no hotspot redirection on port 80/443 and their DNS server works > properly, and your wifi was secure, you would then get their forward > and the above would work. If it is an open wifi, we would not install Since the user is setting things up, they can pick whether it's open or protected wifi. We don't control that. > the forward and you would not get there. but in the current setup, you > can pick "hotspot login" mode and it puts their DNS in place, and than > you will reach it. Note that manual hotspot login sessions require you Ok, that could be a problem. This is a user setting up wifi on a router they just bought, so it has no upstream connection yet, is not yet configured at all, and they are just following the directions in the printed brochure they got with the router. Which obviously won't say anything about "hotspot login" mode. Also, this is the procedure you follow if you reset the router to factory defaults, which support people sometimes tell you to do. So we'd run into the issue if/when the user contacted Netgear technical support too. Dan > to manually mark them for "reprobe" as well because apparently we cannot > probe for it because you manually overrode it. If you switch networks, > and bring up the VPN, you'll encounter weird things. While still in > hotspot mode, the VPN forward put into unbound is not active because you > are not using unbound yet (until you hit reprobe to leave "hotspot > signon" mode. > > Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, 14 Apr 2014, Dan Williams wrote: But another scenario I've seen: older Netgear routers which intercept "www.routerlogin.net" as the setup page. The instructions literally are: 1) connect your computer to the router with a cable 2) go to www.routerlogin.net 3) follow the setup guide instructions Any idea how dnssec-trigger + unbound would handle this? Since it's router setup, maybe spawning the whole new window for the "portal" would work, but you'd want to make sure the window didn't go away or DNS didn't change until the user was done setting up the router. I don't know what they do when you query for anything else. If there is no hotspot redirection on port 80/443 and their DNS server works properly, and your wifi was secure, you would then get their forward and the above would work. If it is an open wifi, we would not install the forward and you would not get there. but in the current setup, you can pick "hotspot login" mode and it puts their DNS in place, and than you will reach it. Note that manual hotspot login sessions require you to manually mark them for "reprobe" as well because apparently we cannot probe for it because you manually overrode it. If you switch networks, and bring up the VPN, you'll encounter weird things. While still in hotspot mode, the VPN forward put into unbound is not active because you are not using unbound yet (until you hit reprobe to leave "hotspot signon" mode. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, 2014-04-14 at 10:21 -0400, Paul Wouters wrote: > > Or how would you suggest this is solved. For arguments sake lets > > say: > > > > SSID: myawesomeopenhotspot > > DHCP provides no domain-name info. > > I CNAME all records to my.hotspot. until authenticated. > > If this does not do http(s) redirection, than it is a very very broken > setup. You would also need to block port 53 to prevent people using > 8.8.8.8 to bypass your authentication. So I do not see this in the wild > (and I've done the hard work of sitting in many coffee shops for > science). hotspots tend to intercept port 80 to a mini web server that > only serves a redirect, sometimes without any DNS name, often with a DNS > name only resolvable by using their DNS. And that is fully supported by > the current solution. Many of the captive portals I've seen block all access to anything except the portal login. You don't get to ping anything, you don't get to DNS anything (let alone 8.8.8.8) and you certainly don't get to send traffic outside the portal. Only when you've authenticated does it release you. Sometimes that's done with VLANs and DHCP renewal, sometimes it's done internally with firewall rules or something. But another scenario I've seen: older Netgear routers which intercept "www.routerlogin.net" as the setup page. The instructions literally are: 1) connect your computer to the router with a cable 2) go to www.routerlogin.net 3) follow the setup guide instructions Any idea how dnssec-trigger + unbound would handle this? Since it's router setup, maybe spawning the whole new window for the "portal" would work, but you'd want to make sure the window didn't go away or DNS didn't change until the user was done setting up the router. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> > >> unbound does not really care about transparent proxy's on port 53. As > >> long as they don't break DNS (and DNSSEC). If they redirect port 53 to > >> some broken DNS server, unbound will try to work around it. If port 53 > >> is broken it will attempt DNS over port 80 of various fedoraproject DNS > >> servers, or DNS over TLS on port 443. > > > > How do you setup DNS over TLS? > > Unbound has this capability already build in. unbound-control activates > via (currently via dnssec-triggerd, in the future via NM) using the > keywords tcp-upstream or ssl-upstream. I meant for say bind, but okay. > > > It's not as much the case, which makes me happier, but I want to know > > the conditions on which you decide a DNS server is "dodgy" or not. > > For a detailed list you will have to check the source code. But it > includes thing like DNSSEC records, proper wildcard NSEC(3) records, > CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older > versions of common DNS software. Cases the IETF actually experienced in > the wild. IE, If I have an out of box bind9 setup with a few zones, or even 100s of zones, these cases should never be triggered. I would hate to see the "dodgy DNS" check giving a false positive on networks that are actually sane ... Such checks need to be conservative in their triggers IMO. > > >>> * If a forwarder exists on the network, unbound uses it for all queries. > >> > >> Yes, but not for open wifi. Only for physical wire and secured wifi. > > > > Okay. Can this point be made clear on the proposal page? Also the > > conditions for Physical wire, and secured wifi? > > Yes, we can do that. Thanks. > > okay, but lets combine these two points. My ISP mucks with the TTL of > > some website from say 300 to 3000. Unbound would respect this to > > that amount, or to the TTL max (Which is still 86400 iirc). If you > > aren't flushing the cache between networks you could end up with: > > > > * Suboptimal routes causing a poor user experience. > > * Incorrect cached zone data moving between networks with different DNS > > views of the world. > > If we believe that artificial increase of TTL is a common manglement, we > can have dnssec-trigger (or the NM integrated version of that) check for > such mangling. I'm reluctant to try and solve every _imaginable_ problem > out there. If your ISPs badness causes suboptimal routes, than that's > not the end of the world, and you have your ISP to blame. One ISP > shouldn't be responsible for every fedora user flushing caches all the > time. Let's deal with this problem when we actually find it is a real > world problem. It actually is quite common from certain Australian ISPs especially the "cheap" ones (You get what you pay for ... ) Even if we ignore the TTL mangling, the first issue of incorrect cached zone data moving between networks is a real world issue IMO. As previously mention, split view business networks. I believe you have said this is solved by flushing "." forwarder between networks that are "secure". > > * On an open (Insecure) access point, unbound bypasses the local > > forwarder, except for names listed in the single valued attribute > > "options domain-name" from dhcp > > No, we cannot do that. As I said, a rogue hotspot could give the > domain-name "corp.paypal.com" to fool me into thinking I'm connecting > to my internal corporate network. We cannot automatically insert those > forwards on open wifi, unless the user manually performs an override. Okay, This is another point to make clear on the wiki. I thought this was what you were saying was the case on open wifi. > > > * On a secure network (Encrypted wifi, lan) unbound will use the > > forwarders as provided by DHCP. > > Provided they are functional (eg don't break DNSSEC) Again, can you on the wiki detail the "functional" requirements. The reason I ask these are documented, is so that when other network admins (like myself) come along, you have already had the argument and provided the justification and detailed explanations of these "edge cases". > > > * Unbound will flush the cache between authenticated networks. (If I > > read your last point correctly) > > If we did a "." forward, yes. Moved ... > > > > > Ignoring the TTL change, lets just look at flushing between network > > > state change. This would solve both the dot points listed. You only need > > > to rebuild the cache on first network reconnect meaning: > > > > "only rebuild"? You are asking everyone else to do hundreds of queries for > > each time to join their 3G network. Remember, when validating, you don't > > just have one record for a queried A record. Since you need to recurse > > and do all the intermediate queries too because otherwise you don't have > > the records to do full DNSSEC validation. It's not a reasonably thing to > > flush the cache. We are working hard on ensuring the user _hits_ their > > cache and gains speed up (including pre-
Re: default local DNS caching name server
On Mon, 14 Apr 2014, William Brown wrote: This seems like a sane(ish) method of doing this. What happens if the hotspot page is down? Why not use a mirror-like setup with yum where you try 2 or 3 mirrors and if they fail then you declare it to be a portal? It has multiple A records matching the redundancy of the fedora infrastructure. *how* can you tell if it's dodgy. You can tell captivity from above, but you can't easily see if an ISP is say TTL tampering or data tampering? TTL tampering does not really affect our operation. When caches are chained, you always get lower TTLs. That's how cached data works. Raising the TTL is only allowed within our confines. Data tampering is detectable by DNSSEC. For those domains that are not protected by DNSSEC we cannot detect tampering. If the publisher want their data integrity, they will have to sign their zones. unbound does not really care about transparent proxy's on port 53. As long as they don't break DNS (and DNSSEC). If they redirect port 53 to some broken DNS server, unbound will try to work around it. If port 53 is broken it will attempt DNS over port 80 of various fedoraproject DNS servers, or DNS over TLS on port 443. How do you setup DNS over TLS? Unbound has this capability already build in. unbound-control activates via (currently via dnssec-triggerd, in the future via NM) using the keywords tcp-upstream or ssl-upstream. Again, how can you guarantee that the fedora infrastructure won't go down? My devils advocate points out we are adding more reliance on "third party" infrastructure here. Could it again be a case similar to the mirrors where you can "become" a fedoraproject DNS node to help load balance? Not yet, but it is a thought. Although it is probably more stable and better to than see about getting sponsored services from one of the large ANYcast DNS cloud providers. Note that when you get to the point of needing port 80 or 443 for DNS, you are arguably already on a pretty disfunctional rogue network where you probably shouldn't be on. It hampers your (DNSSEC) security. So you can see these services as "better than disconnecting from the network". It's not as much the case, which makes me happier, but I want to know the conditions on which you decide a DNS server is "dodgy" or not. For a detailed list you will have to check the source code. But it includes thing like DNSSEC records, proper wildcard NSEC(3) records, CNAME support, EDNS0 support, packet sizes, etc. The known bugs in older versions of common DNS software. Cases the IETF actually experienced in the wild. * If a forwarder exists on the network, unbound uses it for all queries. Yes, but not for open wifi. Only for physical wire and secured wifi. Okay. Can this point be made clear on the proposal page? Also the conditions for Physical wire, and secured wifi? Yes, we can do that. There are also a number of tethering situations that may actually be mis-interpreted as secure. IE my phone has a WPA2 hotspot with DNS that goes via 3g. How does unbound treat this? It would only see the secure wifi ... We cannot protect against wired or secure wifi running insecure DNS. We do run our tests and if it works install the forward. If it fails to work we won't install the forward. Consider also some wifi hotspots have their own "local" zones that are needed, so again, I do think that unbound should use the local forwarder irrespective of network security, because else you may risk breaking things. You sometimes cannot, because often those hotspot routers are old and broken and have crappy DNS proxy/mangling, breaking DNSSEC. That's the premise of how this entire DNS mess started - we could not use DNSSEC when using DNS servers obtained from the network. Anyone injecting rogue domains (what you call "local zones") cannot be distinguished from an attack. Those hotspots should use proper DNS names and/or http redirection for those local zones. Although note that currently dnssec-trigger does give you the option to remain in "insecure mode" which would use the local DNS, and give access to those zones. Or how would you suggest this is solved. For arguments sake lets say: SSID: myawesomeopenhotspot DHCP provides no domain-name info. I CNAME all records to my.hotspot. until authenticated. If this does not do http(s) redirection, than it is a very very broken setup. You would also need to block port 53 to prevent people using 8.8.8.8 to bypass your authentication. So I do not see this in the wild (and I've done the hard work of sitting in many coffee shops for science). hotspots tend to intercept port 80 to a mini web server that only serves a redirect, sometimes without any DNS name, often with a DNS name only resolvable by using their DNS. And that is fully supported by the current solution. There are many possible scenarios to come up with that will not work. There are manual overrides for that. In my years of experience, these kind of problems are far mor
Re: default local DNS caching name server
On Mon, Apr 14, 2014 at 02:07:07PM +0200, Juan Orti Alcaine wrote: > One thing I would like to note is that in machines which don't have > a hardware clock, I had problems starting bind and unbound, because > the date was back to 1970 in each boot, so the root dns key was not > yet valid and there were no valid dns resolvers to update time by > ntp. I had to hardcode some ntp servers IP addresses to perform the > ntp queries at boot time. > > This was using the OpenWrt distro in a mips router, I don't know if > we can face this kind of problem in ARM machines. I guess all x86 > have hardware clock, doesn't they? The NTP Bootstrapping problem is well known. There is an effort to deal with that here (in the context of dnsmasq DNSSEC on OpenWRT/CeroWRT): http://comments.gmane.org/gmane.comp.embedded.cerowrt.devel/2244 Search for the word "prototype" to find a description of one implementation. "The nice thing about this switch to dnsmasq is that it does validation of the chain, just ignoring validity times; which presumably would make it harder to exploit as you'd need an actual valid key, rather than just be able to spoof the packets reply of the non-validated query.." There are many other ideas in that thread. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
One thing I would like to note is that in machines which don't have a hardware clock, I had problems starting bind and unbound, because the date was back to 1970 in each boot, so the root dns key was not yet valid and there were no valid dns resolvers to update time by ntp. I had to hardcode some ntp servers IP addresses to perform the ntp queries at boot time. This was using the OpenWrt distro in a mips router, I don't know if we can face this kind of problem in ARM machines. I guess all x86 have hardware clock, doesn't they? Regards, Juan. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Mon, 2014-04-14 at 00:42 -0400, Paul Wouters wrote: > On Mon, 14 Apr 2014, William Brown wrote: > > > What is a "captivity-sign" as you so put it? > > Check for clean port 80. It fetches the url specified in > dnssec-triggerd.conf's url: option > (default http://fedoraproject.org/static/hotspot.txt) > > If it returns a redirect or a page that does not contain the exact text > "OK" it knows a hotspot has intercepted the page and will prompt the > user to login to the hotspot. It the user agrees, resolv.conf is filled > in with the DHCP obtained values and it fires of xdg-open to the page > http://hotspot-nocache.fedoraproject.org/ which is a special DNS entry > with TTL=0 so it can never be cached (so we will go through the DNS lies > that are told about the name) > > When port 80 becomes clean, it is assumed you have "logged on" > and it then runs various DNS/DNSSEC tests against TLD servers for known > features and bugs in old DNS software. This will determine if DNS is > still messed with. If the forwarder shows broken behaviour, it is > attempted to bypass it as I described before. > This seems like a sane(ish) method of doing this. What happens if the hotspot page is down? Why not use a mirror-like setup with yum where you try 2 or 3 mirrors and if they fail then you declare it to be a portal? > >> sudo unbound-control forward_add starfish 10.1.2.3. > >> sudo unbound-control flush starfish > >> sudo unbound-control flush_requestlist > >> > >> When you leave the network, forward_remove is called. > >> > >> sudo unbound-control forward_remove starfish > >> sudo unbound-control flush startfish > >> sudo unbound-control flush_requestlist > > > > Okay, so lets expand this to my workplace, that run's a University > > network. We have thousands of students connected. Now, we have many > > zones on our network, from services.university.edu university.edu, > > medicalcenter.org, ersearch.com etc etc. > > > > We can't possibly put all of these into our "domain-name" dhcp option. > > iirc it's a single value attribute anyway. > > As we indicated, for "trusted" networks (LAN, secure WIFI) a domain of > "." will be used which means "forward everything". This does NOT mean we > stop being a recursor. We still recursive because we need tod perform > DNSSEC validation. We just use the available DNS cache of the local > network - which also gets us your internal-only domains. This point was not made clear. Will summarise at the bottom ... > > Yes. The problem here is the dodgy ISP. If they are dodgy enough, > unbound will bypass them anyway. If we need to add an NM option for > "don't use this dodgy ISPs DNS servers" we can also add that. > > > But you can't really tell what's a dodgy DNS and what's not. > > Yes we can. There is both dnssec-trigger and some other software that > runs various tests for this. *how* can you tell if it's dodgy. You can tell captivity from above, but you can't easily see if an ISP is say TTL tampering or data tampering? > > Consider also, that some ISP's force all port 53 traffic to their own > > DNS servers too. How does unbound know when the ISP is forcing this? > > unbound does not really care about transparent proxy's on port 53. As > long as they don't break DNS (and DNSSEC). If they redirect port 53 to > some broken DNS server, unbound will try to work around it. If port 53 > is broken it will attempt DNS over port 80 of various fedoraproject DNS > servers, or DNS over TLS on port 443. How do you setup DNS over TLS? Again, how can you guarantee that the fedora infrastructure won't go down? My devils advocate points out we are adding more reliance on "third party" infrastructure here. Could it again be a case similar to the mirrors where you can "become" a fedoraproject DNS node to help load balance? > > > Essentially, what I'm hearing at the moment, is that the proposal isn't > > just a caching DNS server: It's a DNS server that will be: > > > > * DNSSEC > > * Caching > > * Attempts to always bypass my local DNS forwarder. > > I hope I clarified it now that your third bullet point is not the case. It's not as much the case, which makes me happier, but I want to know the conditions on which you decide a DNS server is "dodgy" or not. > > I'm glad that the NM integration is being considered, that will help. I > > might not be afraid to touch a CLI, but I do think of users who use the > > GUI only. > > This is why we did not want to force everyone on dnssec-triggerd. We > know that solution is not good enough for non-devs. Agreed. > > > In summary, all I ask is that: > > > > * If a forwarder exists on the network, unbound uses it for all queries. > > Yes, but not for open wifi. Only for physical wire and secured wifi. Okay. Can this point be made clear on the proposal page? Also the conditions for Physical wire, and secured wifi? There are also a number of tethering situations that may actually be mis-interpreted as secure. IE my phone has a WPA2 h
Re: default local DNS caching name server
On Mon, 14 Apr 2014, William Brown wrote: What is a "captivity-sign" as you so put it? Check for clean port 80. It fetches the url specified in dnssec-triggerd.conf's url: option (default http://fedoraproject.org/static/hotspot.txt) If it returns a redirect or a page that does not contain the exact text "OK" it knows a hotspot has intercepted the page and will prompt the user to login to the hotspot. It the user agrees, resolv.conf is filled in with the DHCP obtained values and it fires of xdg-open to the page http://hotspot-nocache.fedoraproject.org/ which is a special DNS entry with TTL=0 so it can never be cached (so we will go through the DNS lies that are told about the name) When port 80 becomes clean, it is assumed you have "logged on" and it then runs various DNS/DNSSEC tests against TLD servers for known features and bugs in old DNS software. This will determine if DNS is still messed with. If the forwarder shows broken behaviour, it is attempted to bypass it as I described before. sudo unbound-control forward_add starfish 10.1.2.3. sudo unbound-control flush starfish sudo unbound-control flush_requestlist When you leave the network, forward_remove is called. sudo unbound-control forward_remove starfish sudo unbound-control flush startfish sudo unbound-control flush_requestlist Okay, so lets expand this to my workplace, that run's a University network. We have thousands of students connected. Now, we have many zones on our network, from services.university.edu university.edu, medicalcenter.org, ersearch.com etc etc. We can't possibly put all of these into our "domain-name" dhcp option. iirc it's a single value attribute anyway. As we indicated, for "trusted" networks (LAN, secure WIFI) a domain of "." will be used which means "forward everything". This does NOT mean we stop being a recursor. We still recursive because we need tod perform DNSSEC validation. We just use the available DNS cache of the local network - which also gets us your internal-only domains. Sure, lets agree we "need" dnssec, and that follows that we need cache. Set cache times to be deliberately low so that silly network admin's don't break things (Even 300). I still don't see a need for artificially lowered cache times. Don't try and by pass the local network DNS: There are more network configurations in the world than you or I can contemplate, and bypassing this *will* break things for people. The publisher determines the TTL, not the consumer. And if we add a forward for "." meaning all domains, that we also run a cache flush for "." meaning all domains. So I don't think TTL matters in this case at all. If you want to cache, then you can't assume that what I cache on network A will be valid on network B. Consider the home user with the dodgy ISP that set's all TTLs to say 30 days. Do you want that user to take that cached entry to a working network and be using that cache for 30 days? (Or whatever unbound sets it TTL max to.) Yes. The problem here is the dodgy ISP. If they are dodgy enough, unbound will bypass them anyway. If we need to add an NM option for "don't use this dodgy ISPs DNS servers" we can also add that. But you can't really tell what's a dodgy DNS and what's not. Yes we can. There is both dnssec-trigger and some other software that runs various tests for this. There are plenty of good ISP's with well configured DNS systems that you *should* use as a forwarder. Again, you can't determine what zones exist in this DNS server so that you can use it "just for those" and bypass it for all else. See earlier discussion. If a wire or secure wifi, and working ISP DNS, we will use it. And flush it. Consider also, that some ISP's force all port 53 traffic to their own DNS servers too. How does unbound know when the ISP is forcing this? unbound does not really care about transparent proxy's on port 53. As long as they don't break DNS (and DNSSEC). If they redirect port 53 to some broken DNS server, unbound will try to work around it. If port 53 is broken it will attempt DNS over port 80 of various fedoraproject DNS servers, or DNS over TLS on port 443. Essentially, what I'm hearing at the moment, is that the proposal isn't just a caching DNS server: It's a DNS server that will be: * DNSSEC * Caching * Attempts to always bypass my local DNS forwarder. I hope I clarified it now that your third bullet point is not the case. Sure it helps. But this is DNSSEC helping, not the cache. I've said everything about caching already. I understand you deem it evil and I explained why I believe you are wrong. We disagree. If DNS cache was the only cause for Windows machines to need a reboot, I'm sure Microsoft would have fixed that by now. Let's remain honest here and say there are a 1001 reasons why Windows users reboot their machines. DNS might be one of them but it has no relationship to the discussion we are having right now. That's deflecting the point. No, bringing up Windows
Re: default local DNS caching name server
> > But you can't account for every captive portal in the world. This is why > > the cache is a bad idea, because you can't possibly account for every > > system that is captive like this. > > Yes we can by monitoring for "captivity signs" when a new network is > joined. Again, please yum install dnssec-trigger on your laptop and > start the dnssec-trigger applet once, and go have a coffee outside. > Let us know your experience. What is a "captivity-sign" as you so put it? > > > > What if I call my network .concrete. Or .starfish. Or any other weird > > thing I have seen on personal networks. Again, you cannot bypass the > > local network DNS as the forwarder. You must respect it. > > We will! If your DHCP has: > > option domain-name-servers 10.1.2.3; > option domain-name "starfish"; > > Then unbound would get a forward configured to use 10.1.2.3 for the domain > .starfish, > basically calling: > > sudo unbound-control forward_add starfish 10.1.2.3. > sudo unbound-control flush starfish > sudo unbound-control flush_requestlist > > When you leave the network, forward_remove is called. > > sudo unbound-control forward_remove starfish > sudo unbound-control flush startfish > sudo unbound-control flush_requestlist Okay, so lets expand this to my workplace, that run's a University network. We have thousands of students connected. Now, we have many zones on our network, from services.university.edu university.edu, medicalcenter.org, ersearch.com etc etc. We can't possibly put all of these into our "domain-name" dhcp option. iirc it's a single value attribute anyway. So how does unbound handle this? Does it bypass my network DNS servers completely for everything that isn't university.edu or a child of? IMO that's not acceptable behaviour. > > >> When connecting to their LAN or secure wifi, same as above for one one > >> forwarding zone. Multiple forwarding zones would need to be configured. > >> It if is an enterprise, they might need their corporate CAs as well as > >> their zones configuration, so a corporate rpm package would make sense. > > > > How do you plan to make this work? You can't magically discover all the > > DNS zones hosted in an enterprise. At my work we run nearly 100 zones, > > and they are all based at different points (IE, a.com, b.com, c.com.) > > You cannot assume a business has just "a.com" and you can forward all > > quieries for subtree.a.com to that network server. > > If you are that large a business, you should really have a corporate > build rpm package with your enterprise information such as local CA, > local zones, etc. DNS forwarder zones can be dropped into > /etc/unbound/*.d/ currently. I would expect we would make this software > neutral via NM integration, where an NM unbound plugin would use those > directories. We could add a per-network option that specifies to use a > forward for "." (everything) instead of just the DHCP specified domain, > or perhaps even do this for trusted (see above) networks. > > However, that should not be the default for open wifi networks for > security reasons. > See above: We can't possibly hope to deploy such a package to students and staff with bring-your-own-device. How do you propose we populate all the needed forwarders for our students (Such, maybe only a few hundred use linux / fedora - but it will cause them to have a negative view of the OS. > > > Again, you *must* respect the DHCP provided DNS server as the forwarder > > else you will savagely break things. > > And not doing anything will cause people to have insecure DNS. So I think > the question should be turned around a little bit. There is a need for > DNSSEC on the end nodes - how can we best facilitate that while trying > to be as supportive of current deployments as we can be? That is what > we are trying to do. If you only counter with "I require insecure DNS > for my network to function" or "all cache is evil", than you are not > openminded enough to the realities of the requirement of DNSSEC support. > Sure, lets agree we "need" dnssec, and that follows that we need cache. Set cache times to be deliberately low so that silly network admin's don't break things (Even 300). Don't try and by pass the local network DNS: There are more network configurations in the world than you or I can contemplate, and bypassing this *will* break things for people. > >>> Case 1: The user doesn't know much about DNS. the ISP might be reliable > >>> or unreliable. If we assume as discussed that the cache is flushed on > >>> network change, they will have an empty cache. > >> > >> The cache is never fully flushed. It is only flushed for the domain > >> obtained via DHCP or VPN, because those entries can change. They are not > >> changed for anything else. If the upstream ISP could have spoofed them, > >> so be it - the publisher of the domains could have used DNSSEC to > >> prevent that from happening. > > > >
Re: default local DNS caching name server
On Sun, Apr 13, 2014 at 10:18 AM, Richard W.M. Jones wrote: Unfortunately NetworkManager can't handle brief network outages without dropping the connection (RHBZ#1022954 comment 3). This isn't desirable for servers that have ethernet and fixed IP addresses. NetworkManager-config-server fixes this, it sets: ignore-carrier=* See https://mail.gnome.org/archives/networkmanager-list/2013-June/msg00159.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 13 Apr 2014, Richard W.M. Jones wrote: So you've gone out of your way to run a daemon but prevent it from working as configured, instead of just reconfiguring it to do what you need. I have to go out of my way to *stop* NetworkManager from running and to configure a fixed IP address. Installing for a static server, even if not running NM, should be no problem for the DNS case. The DNS your put in via kickstart/GUI will be configured as a forwarder for unbound. No need to do anything. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 2014-04-13 at 18:18 +0100, Richard W.M. Jones wrote: > On Sat, Apr 12, 2014 at 04:12:41PM -0400, Simo Sorce wrote: > > So you've gone out of your way to run a daemon but prevent it from > > working as configured, instead of just reconfiguring it to do what you > > need. > > I have to go out of my way to *stop* NetworkManager from running and > to configure a fixed IP address. Oh come on ... > > I have Network Manager and it is extremely simple to configure it to > > keep fixed DNS Servers as well as have static addresses for ethernet > > interfaces. > > Unfortunately NetworkManager can't handle brief network outages > without dropping the connection (RHBZ#1022954 comment 3). This isn't > desirable for servers that have ethernet and fixed IP addresses. Let's try to be constructive here, this is a bug, I remember distinctively discussing delaying dropping ip/interfaces when the link goes down for brief moemnts, and I know that works. Also this is bug is about dhcp interfaces, not statically configured ones, and it is a bug, not intended behavior, also difficult to reproduce. I am not here to proselitize you on the use of NM, but let's not be extreme, NM has greatly improved and keep improving at every release,m and for a lot of users it's really the only *decent* option, I am a bit annoyed by constant, gratuitous and useless 'attacks' to it, and I am not even a NM developer and never even contributed to the project with patches (yet). You don't like it, fine, but let's not come up with the old trite anecdata every time someone mentions NM, it's not useful and derails the conversation to useless bikeshedding. I'd rather go back to the topic: default local DNS caching name server. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote: > On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote: > > On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote: > > > > > A system wide resolver I am not opposed to. I am against a system wide > > > *caching* resolver. > > > > > In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a > > > cache is a severe detriment. > > > > About the above 2, can you explain *why* ? > > A bunch of people here, feel that it would be a great improvement, you > > keep saying it is doomsday, yet I haven't seen a concise explanation of > > why that would be (maybe I overlooked, apologies if so). > > > > > > > I disable the DNS cache in firefox with developer tools. > > > > So you will be able to do the same by setting 1 configuration option in > > unbound, or you could disable the resolver entirely. > > > > Can you tell why *everybody* should have the cache disabled by default ? > > > > > Additionally, a short TTL is good, for this situation, but it can't fix > > > everything. > > > > Paul mentioned the single configuration option need to make your > > resolver tweak the TTL locally, what else do you need ? And again why > > your preference should be the default ? What compelling arguments can > > you make ? > > > > Simo. > > Internal and external zone views in a business. These records may > different, and so would need flushing between network interface state > changes. As mentioned unbound does flush away the specific domains, so I will write this one off. We can discuss the fine tuning for sure but it is not a general concern. > Additionally, local DNS caches may issues and delay diagnosis. Just like about everything, I will write this off as well as I've seen lack of caching causing the same difficult to diagnose issues (two collaborating application getting different IPs for the same service and inconsitencies between the 2 endpoints causing odd results). So I do not think this is a generally valid concern, in the sense that the benefits outweight the potential issues IMO. > It's also not *needed* in a lot of setups. The business cases were to > show that these caching layers already exist on these networks. It would > be duplication of effort. Not really, it would reduce unnecessary traffic, and give you for free a bit of server affinity in general a good thing for most cases. Whether it is *needed* or not depends on the situation, however my sensation over many years is that a cache would bring more benefits than not. I have had a lot more issues with flaky networks on machine w/o a cache than one those with a cache, browsing in particular becomes erratic on networks with high packet loss or flakey DNS server when you do not have a cache as UDP packets are easily lost while TCP connection can retry and recover more quickly, so the DNS is the one that causes more issues and delays for the browser. > In businesses, it's also common place to have a low-ish ttl (Say 5 > minutes) and when a system is migrated, they swap the A/ records to > the new system. The dns servers on the network are updated, but the > workstation has the old record cached. If the TTL is 5 minutes, the cache will expire in 5 minutes too. > Without a local cache, they would query the local server again, which is > relatively cheap. And tey will do the same with a local cache, local caches *will* respect TTLs of course! > IE: It keeps > users happier even if they only needed to wait 5 minutes. Some people > like things to be instant. And some people want unicorns, nobody prevent those people from disabling this default. My personal experience is that these are rare events and are not that important, and can be properly handled by admins by lowering the TTLs in advance of a planned outage by bringing them down to very short timeouts or even 0. > It's certainly not the end of the world, but it's adding more > complexity, and a potential source of issues. And also a source of benefits, as always it is a matter of balance, and with the advent of DNSSEC I personally think the balance has definitely tipped in favor of a *default* local resolver cache. (note: the *default*, it means it is not bolted on, you can easily replace it like you do for other services, for example the first thing I do on my machines is to throw sendmail out the window and bring in postfix, it's not a big deal, kisckstarts makes it trivial too). > There is additionally, some confusion: It sounds like Paul wants to add > the resolver to only forward queries for the local domain name to the > local name servers. But this is impossible to discover all possible > local domain names that are available. I think the default will be to forward everything to the DHCP provided nameservers, and forward to specific servers per specific domain on resources like VPN (unless otherwise configured, and there are already knobs for that). > tl;dr - DNSSEC I believe is a good thing (Even if
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 04:12:41PM -0400, Simo Sorce wrote: > So you've gone out of your way to run a daemon but prevent it from > working as configured, instead of just reconfiguring it to do what you > need. I have to go out of my way to *stop* NetworkManager from running and to configure a fixed IP address. > I have Network Manager and it is extremely simple to configure it to > keep fixed DNS Servers as well as have static addresses for ethernet > interfaces. Unfortunately NetworkManager can't handle brief network outages without dropping the connection (RHBZ#1022954 comment 3). This isn't desirable for servers that have ethernet and fixed IP addresses. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 2014-04-13 at 16:29 +0930, William Brown wrote: > > That depends. You need caching for DNSSEC validation, so really, > every > > device needs a cache, unless you want to outsource your DNSSEC > > validation over an insecure transport (LAN). That seems like a very > bad > > idea. > > If your lan is insecure, you have other issues. That isn't the problem > you are trying to solve. > I keep seeing this repeated by you and Harald. I am truly in awe that your networks are *secure*, however that is not the common case, networks are routinely breached by zombified machines or are insecure by default (wifi, or very large networks where anyone can plug in). Basically if any of the machines on the network can be compromised the network is not secure anymore. Finally you can't certainly trust network as large as common ISPs. All these networks need to be treated as insecure by default. You cannot trust a DNS server not on your machine to do DNSSEC resolution for you or, as soon as you want to start using DANE, TLSA, etc.. you are a sitting duck, and people will be able to MITM you extremely easily. The default needs to cater for these issues. But of course it is just a default, on your network you'll be able to change the resolvers however you want. The only thing I agree on is that the default MUST use the forwarders provided by the local DHCP unless the user explicitly configured otherwise. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 13 Apr 2014, William Brown wrote: PS: It also seemed like the proposal was to *bypass* the networks provided forwarders from DHCP. This *is* a serious issue if it's the case. We only bypass DHCP provided forwarders that are broken. We actually WANT to use them as much as possible, because we DO believe in caching, and we DO want to use ISP caches whereever possible. But if they run broken or malicious DNS servers, we do our best to bypass those servers. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 13 Apr 2014, William Brown wrote: Yes. It depends on the "trustworthiness" of the network and or preconfiguration of some of your own networks you join. Not really: Every network you join, you have to semi-trust. If you don't trust it, why did you join it? You don't always control which networks your device roams on. If I agree to starbucks at my street, my phone will connect to any network named starbucks, even if it is yours. So to draw the line between the user _knowingly_ joining a network, we drew the line at "plug in physically or provided the authentication credentials". Works reasonably well with unbound+dnssec-triger, could use better NM integration for captive portals. But you can't account for every captive portal in the world. This is why the cache is a bad idea, because you can't possibly account for every system that is captive like this. Yes we can by monitoring for "captivity signs" when a new network is joined. Again, please yum install dnssec-trigger on your laptop and start the dnssec-trigger applet once, and go have a coffee outside. Let us know your experience. Case 2: Moderate home user. They have a little knowledge of DNS, and have setup a system like OpenWRT or gargoyle on their router. They have their own zone, .local . This means that their DHCP provides the DNS ip of the router to clients. Same if their wifi is closed (eg WPA2), will need an exception in NM if their wifi is open for the .local forward. What if I call my network .concrete. Or .starfish. Or any other weird thing I have seen on personal networks. Again, you cannot bypass the local network DNS as the forwarder. You must respect it. We will! If your DHCP has: option domain-name-servers 10.1.2.3; option domain-name "starfish"; Then unbound would get a forward configured to use 10.1.2.3 for the domain .starfish, basically calling: sudo unbound-control forward_add starfish 10.1.2.3. sudo unbound-control flush starfish sudo unbound-control flush_requestlist When you leave the network, forward_remove is called. sudo unbound-control forward_remove starfish sudo unbound-control flush startfish sudo unbound-control flush_requestlist When connecting to their LAN or secure wifi, same as above for one one forwarding zone. Multiple forwarding zones would need to be configured. It if is an enterprise, they might need their corporate CAs as well as their zones configuration, so a corporate rpm package would make sense. How do you plan to make this work? You can't magically discover all the DNS zones hosted in an enterprise. At my work we run nearly 100 zones, and they are all based at different points (IE, a.com, b.com, c.com.) You cannot assume a business has just "a.com" and you can forward all quieries for subtree.a.com to that network server. If you are that large a business, you should really have a corporate build rpm package with your enterprise information such as local CA, local zones, etc. DNS forwarder zones can be dropped into /etc/unbound/*.d/ currently. I would expect we would make this software neutral via NM integration, where an NM unbound plugin would use those directories. We could add a per-network option that specifies to use a forward for "." (everything) instead of just the DHCP specified domain, or perhaps even do this for trusted (see above) networks. However, that should not be the default for open wifi networks for security reasons. Again, you *must* respect the DHCP provided DNS server as the forwarder else you will savagely break things. And not doing anything will cause people to have insecure DNS. So I think the question should be turned around a little bit. There is a need for DNSSEC on the end nodes - how can we best facilitate that while trying to be as supportive of current deployments as we can be? That is what we are trying to do. If you only counter with "I require insecure DNS for my network to function" or "all cache is evil", than you are not openminded enough to the realities of the requirement of DNSSEC support. Same, already works if you only need the one domain that is negotiated via the VPN (eg the IKE XAUTH domain). You can negotiate more than one domain on a VPN again, see above. not with IPsec/XAUTH. If more domains can come in via openvpn or something, that I would assume the existing openvpn unbound plugin already deals with that case. If not, please file a bug and we will fix it. We are not suggesting that for LAN or secure wifi. In those cases the forward will be added. However, you don' want those forwards for open wifi or else I can bring up "linksys" push you a forward for your internal.domain.com and mislead you into thinking you would be going over your VPN. This is a more serious problem, than a caching resolver could hope to solve as it shows malicious intent. I'm sorry I don't understand what you are trying to say here. Case 1: The user doesn't know much
Re: default local DNS caching name server
william wrote: > [...] > Internal and external zone views in a business. These records may > different, and so would need flushing between network interface state > changes. Sure, let's make it easy to restart the cache upon such transitions. > Additionally, local DNS caches may issues and delay diagnosis. > > It's also not *needed* in a lot of setups. [...] The cache-hit latency to a local daemon vs. a shared network daemon can be significantly different. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
William Brown wrote: >In businesses, it's also common place to have a low-ish ttl (Say 5 >minutes) and when a system is migrated, they swap the A/ records to >the new system. The dns servers on the network are updated, but the >workstation has the old record cached. Without a local cache, they >would query the local server again, which is relatively cheap. IE: It >keeps users happier even if they only needed to wait 5 minutes. Some >people like things to be instant. If the admins on that network configured a five-minute TTL, it's because they *want* the clients to cache the records for five minutes. They can set the TTL to zero if they want the servers to be queried for every single lookup. And if they're migrating a system they will know this more than five minutes in advance, so they can set a zero TTL temporarily. -- Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
William Brown wrote: >> The cache is never fully flushed. It is only flushed for the domain >> obtained via DHCP or VPN, because those entries can change. They are >> not changed for anything else. If the upstream ISP could have >> spoofed them, so be it - the publisher of the domains could have >> used DNSSEC to prevent that from happening. > >No no no You need to flush *all* entries. Consider what I resolve >www.google.com to. That changes *per* ISP because google provides >different DNS endpoints and zones to ISPs to optimise traffic! So when >I use google at work, I'm now getting a suboptimal route to their >servers! You'll still reach Google, but you'll get a suboptimal route for up to five minutes – provided that you managed to go from home to work and reconnect your laptop in less than five minutes. Big deal. I just looked up www.google.com to check, and I got a TTL of 300 seconds on both A and records. >> You need caching for DNSSEC validation, so really, >> every device needs a cache, unless you want to outsource your DNSSEC >> validation over an insecure transport (LAN). That seems like a very >> bad idea. > >If your lan is insecure, you have other issues. That isn't the problem >you are trying to solve. If admins want to set up firewalls, link-layer encryption, intrusion detection and stuff in an attempt to keep all adversaries out of their LAN, and then have the security of servers and workstations depend on the guarantee that the LAN is secure, then they should have to explicitly configure each computer to trust everybody on the LAN. Fedora can *not* assume that it will only ever be connected to secure, isolated networks. >A home user is likely to toy with things and set a >high-ish ttl, say even 10 minutes, and change records on their server. >Then their records appear broken, because the local cache isn't expired >yet. The kind of user who runs their own DNS at home and tinkers with settings like that, is the kind of person who will learn from the experience and will thereafter know what DNS caching is. >Intermittent network issues for different people on a network? The >cache is allowing some people to work, but masking the issue to them. >It's not allowing people to quickly and effectively isolate issues. You keep repeating this argument, as if it's somehow a bad thing that people can continue to work even when the DNS servers have a temporary problem. To me it sounds more like an argument for why the network admins should disable the cache on their own workstations and leave it enabled on everybody else's, so that the admins will be the first to discover a problem – and that translates to an argument for having a cache by default. -- Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote: > On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote: > > On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote: > > > > > A system wide resolver I am not opposed to. I am against a system wide > > > *caching* resolver. > > > > > In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a > > > cache is a severe detriment. > > > > About the above 2, can you explain *why* ? > > A bunch of people here, feel that it would be a great improvement, you > > keep saying it is doomsday, yet I haven't seen a concise explanation of > > why that would be (maybe I overlooked, apologies if so). > > > > > > > I disable the DNS cache in firefox with developer tools. > > > > So you will be able to do the same by setting 1 configuration option in > > unbound, or you could disable the resolver entirely. > > > > Can you tell why *everybody* should have the cache disabled by default ? > > > > > Additionally, a short TTL is good, for this situation, but it can't fix > > > everything. > > > > Paul mentioned the single configuration option need to make your > > resolver tweak the TTL locally, what else do you need ? And again why > > your preference should be the default ? What compelling arguments can > > you make ? > > > > Simo. > > Internal and external zone views in a business. These records may > different, and so would need flushing between network interface state > changes. > > Additionally, local DNS caches may issues and delay diagnosis. > > It's also not *needed* in a lot of setups. The business cases were to > show that these caching layers already exist on these networks. It would > be duplication of effort. > > In businesses, it's also common place to have a low-ish ttl (Say 5 > minutes) and when a system is migrated, they swap the A/ records to > the new system. The dns servers on the network are updated, but the > workstation has the old record cached. Without a local cache, they would > query the local server again, which is relatively cheap. IE: It keeps > users happier even if they only needed to wait 5 minutes. Some people > like things to be instant. > > > It's certainly not the end of the world, but it's adding more > complexity, and a potential source of issues. > > > There is additionally, some confusion: It sounds like Paul wants to add > the resolver to only forward queries for the local domain name to the > local name servers. But this is impossible to discover all possible > local domain names that are available. > > > tl;dr - DNSSEC I believe is a good thing (Even if it's rare). I don't > think there are "benefits" to caching except in a minor number of cases > where existing DNS caching mechanisms aren't in place. We are adding a > layer of caching complexity that doesn't solve a real problem. > > PS: It also seemed like the proposal was to *bypass* the networks provided forwarders from DHCP. This *is* a serious issue if it's the case. -- William Brown signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote: > On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote: > > > A system wide resolver I am not opposed to. I am against a system wide > > *caching* resolver. > > > In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a > > cache is a severe detriment. > > About the above 2, can you explain *why* ? > A bunch of people here, feel that it would be a great improvement, you > keep saying it is doomsday, yet I haven't seen a concise explanation of > why that would be (maybe I overlooked, apologies if so). > > > > I disable the DNS cache in firefox with developer tools. > > So you will be able to do the same by setting 1 configuration option in > unbound, or you could disable the resolver entirely. > > Can you tell why *everybody* should have the cache disabled by default ? > > > Additionally, a short TTL is good, for this situation, but it can't fix > > everything. > > Paul mentioned the single configuration option need to make your > resolver tweak the TTL locally, what else do you need ? And again why > your preference should be the default ? What compelling arguments can > you make ? > > Simo. Internal and external zone views in a business. These records may different, and so would need flushing between network interface state changes. Additionally, local DNS caches may issues and delay diagnosis. It's also not *needed* in a lot of setups. The business cases were to show that these caching layers already exist on these networks. It would be duplication of effort. In businesses, it's also common place to have a low-ish ttl (Say 5 minutes) and when a system is migrated, they swap the A/ records to the new system. The dns servers on the network are updated, but the workstation has the old record cached. Without a local cache, they would query the local server again, which is relatively cheap. IE: It keeps users happier even if they only needed to wait 5 minutes. Some people like things to be instant. It's certainly not the end of the world, but it's adding more complexity, and a potential source of issues. There is additionally, some confusion: It sounds like Paul wants to add the resolver to only forward queries for the local domain name to the local name servers. But this is impossible to discover all possible local domain names that are available. tl;dr - DNSSEC I believe is a good thing (Even if it's rare). I don't think there are "benefits" to caching except in a minor number of cases where existing DNS caching mechanisms aren't in place. We are adding a layer of caching complexity that doesn't solve a real problem. -- William Brown signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> > > Proposal is to add a local caching DNS server to fedora systems. This > > may or may not accept a DHCP provided forwarder(?). > > Yes. It depends on the "trustworthiness" of the network and or > preconfiguration of some of your own networks you join. Not really: Every network you join, you have to semi-trust. If you don't trust it, why did you join it? There are too many cases where the network admin is correct, and does the right thing. It's more the exception I think that the network is truly untrustworthy. > > > Case 1: Standard home user. Has little knowledge of DNS, and a router > > provided by their ISP. DHCP provides the laptop with the DNS ip of the > > router, which then acts as a forwarder to the ISP > > Works reasonably well with unbound+dnssec-triger, could use better NM > integration for captive portals. But you can't account for every captive portal in the world. This is why the cache is a bad idea, because you can't possibly account for every system that is captive like this. > > > Case 2: Moderate home user. They have a little knowledge of DNS, and > > have setup a system like OpenWRT or gargoyle on their router. They have > > their own zone, .local . This means that their DHCP provides the DNS ip > > of the router to clients. > > Same if their wifi is closed (eg WPA2), will need an exception in NM if > their wifi is open for the .local forward. What if I call my network .concrete. Or .starfish. Or any other weird thing I have seen on personal networks. Again, you cannot bypass the local network DNS as the forwarder. You must respect it. > > > Case 3: Power home user. They likely have their own fedora router server > > or some other system setup. They run their own bind / named instance on > > their network, with their own zone or two. They have DHCP setup, perhaps > > to use DDNS updates to named. > > Same as above. > > > Case 4: Small business workstation. Likely the small business, like the > > power home user, has their own name server. It may be Windows DNS from > > AD, or bind. > > Same as above. > > > Case 5: Medium / Large business workstation. It's nearly guaranteed that > > the business runs their own zones. They have their own extensive, well > > organised bind / named setup. > > When connecting to their LAN or secure wifi, same as above for one one > forwarding zone. Multiple forwarding zones would need to be configured. > It if is an enterprise, they might need their corporate CAs as well as > their zones configuration, so a corporate rpm package would make sense. How do you plan to make this work? You can't magically discover all the DNS zones hosted in an enterprise. At my work we run nearly 100 zones, and they are all based at different points (IE, a.com, b.com, c.com.) You cannot assume a business has just "a.com" and you can forward all quieries for subtree.a.com to that network server. Again, you *must* respect the DHCP provided DNS server as the forwarder else you will savagely break things. > > > Case 6: Fedora server in a small business: Same as the workstation, > > likely AD or bind in the office. > > Same as previous > > > Case 7: Fedora server in the large business. Same as the workstation. > > Same as previous > > > Case 8: Road warrior to the power home, small business, or large > > business. Uses VPN, and needs access to the DNS provided by the push > > dhcp / dns options from their vpn tunnel. > > Same, already works if you only need the one domain that is negotiated > via the VPN (eg the IKE XAUTH domain). You can negotiate more than one domain on a VPN again, see above. > > > Now, in all of these cases the system local DNS cache *must* forward to > > the local DNS server. You can't at the OS distinguish between any of > > these cases with just the DHCP record or lease. It is unreasonable to > > ask everyone to manually setup DNS on every network they join. You must > > have the forwarder set to the DNS provided by DHCP so that you can > > access the local network resources. You cannot suggest bypassing these. > > We are not suggesting that for LAN or secure wifi. In those cases the > forward will be added. However, you don' want those forwards for open > wifi or else I can bring up "linksys" push you a forward for your > internal.domain.com and mislead you into thinking you would be going > over your VPN. This is a more serious problem, than a caching resolver could hope to solve as it shows malicious intent. > > > Case 1: The user doesn't know much about DNS. the ISP might be reliable > > or unreliable. If we assume as discussed that the cache is flushed on > > network change, they will have an empty cache. > > The cache is never fully flushed. It is only flushed for the domain > obtained via DHCP or VPN, because those entries can change. They are not > changed for anything else. If the upstream ISP could have spoofed them, > so be it - the publisher of the domains could have used DNSSEC to > prevent that f
Re: default local DNS caching name server
Am 13.04.2014 08:42, schrieb Simo Sorce: * DNS cache should be flushed on route or interface state change. > > I do not see why, the only reason to flush a cache is when there is a > DNS change (new interface, eg VPN coming up, or going away) because if i change my routing from ISP to VPN i want to access the company severs over the VPN - any of them changing the default root is a common way for such a switch >> the cache already is running in my LAN for good reasons > > That's a different cache, however if you feel strongly you will be able > to turn off the local caching dns server on your machines, at your > option. > >> that DNS cache is pushed with DHCP > > Forwarders are pushed via DHCP, not caches says who? you or better the one built the network and services? the via DHCP pushed DNS servers are caches because they do not forward anything, they are doing recursion - if youre DNS servers are only forwarders consider to change that frankly the main reason i stepped in that thread at all is that people started to talk about recursion / forwarding without understand that both terms in case of DNS >> that DNS cache already does DNSSEC validation > > Which is useless in the *general* case. You may think your physical > security is perfect, that;s great, but for everybody else, trusting the > network is not ok, that's why more an more people de[ploy TLS or GSSAPI > in internal networks too. > The era of the clear text trusted private network is coming to an end, > whether you like it or not. > >> if you don't trust the network itself you are lost anyways > > Let me troll a bit, this is why you do all your banking without > HTTPS ? :-) that is a completly different story, you enter a HTTPS URL manually or triggered by HSTS, so you request a encrypted connection from the very first start in case of DNS there is nothing encrypted at start resolving and if i proper manipulate the network you are in i hide any DNSSEC response from you (deep packet inspection) > I am strongly in favor of a DNS cache on Fedora, and I would even > seriously consider any proposal of making it the default on Fedora > Server too as long as it is not a hard wired dependency. i don't need additional DNS servers on any system the systems are running BIND are doing that with good reasons the systems running Unbound as local cache doing that for good reasons (MTA servers) the systems running dnsmasq are doing it for good reasons (Reverse-proxy with own DNS view) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote: > A system wide resolver I am not opposed to. I am against a system wide > *caching* resolver. > In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a > cache is a severe detriment. About the above 2, can you explain *why* ? A bunch of people here, feel that it would be a great improvement, you keep saying it is doomsday, yet I haven't seen a concise explanation of why that would be (maybe I overlooked, apologies if so). > I disable the DNS cache in firefox with developer tools. So you will be able to do the same by setting 1 configuration option in unbound, or you could disable the resolver entirely. Can you tell why *everybody* should have the cache disabled by default ? > Additionally, a short TTL is good, for this situation, but it can't fix > everything. Paul mentioned the single configuration option need to make your resolver tweak the TTL locally, what else do you need ? And again why your preference should be the default ? What compelling arguments can you make ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 2014-04-13 at 00:52 -0400, Felix Miata wrote: > On 2014-04-12 16:12 (GMT-0400) Simo Sorce composed: > > On Sat, 2014-04-12 at 13:11 -0400, Felix Miata wrote: > >> I've been doing that myself for years on installations that think my > >> ethernet-only non-wireless LAN host connections need "managing" by > >> NetworkManager, Resolvconf, Wicked or anything else that came along to > >> automagically mis-configure it. > > > So you've gone out of your way to run a daemon but prevent it from > > working as configured, instead of just reconfiguring it to do what you > > need. > > What daemon did I go out of my way to run? I had the impression you said you make the file immutable to prevent one of the mentioned daemons above from touching it. Apologies if I misunderstood. > > I have Network Manager and it is extremely simple to configure it to > > keep fixed DNS Servers as well as have static addresses for ethernet > > interfaces. > > Simple without X running, where I normally perform my elementary > configuration chores in an OFM? When I install, I install minimal, so there > is no X available to tweak the installer's defaults. I usually edit /etc/sysconfig/network-scripts/ifcfg-eth0 (or similar) for headless servers, what's hard about that ? > > I find that today, except extremely rare case, all that people that > > complain about network management tools interfering are people that > > never tried or tried once *years* ago and never checked again. > > Maybe so, but then some of us don't need our networks "managed", only just > configured at installation time, after which they are left untouched for the > remaining lifetime of the installation. Not a reason to throw mud at perfectly valid software and perfectly valid use cases. Defaults need to appeal to the majority of users, they can't please everyone, or they wouldn't be just defaults, they'd be the only option. We are discussing what defaults make sense for Fedora when it come to DNS caching and DNSSEC, my strong belief is that a default DNS cache is a very good idea for the majority of users. Users with special needs like you can simply not bring it in. If you do a minimal install I suspect it won't be present, as in F21 minimal installs will really be tight afaiu. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 2014-04-13 at 06:35 +0200, Reindl Harald wrote: > and if you believe that in a not trustable network you don't > know if you get the signing informations at all - fine, but > you hardly an enforce that with a local software That is the WHOLE point of DNSSEC, really. > if i control the network i control the whle traffic and without > your own satellite link you can't change that It is not necessary, integrity protection allows me to find out if my traffic is getting through or not. If not, though luck. > >> Case 4, 5, 6 and 7: DNS cache, again, isn't needed. > > > > Again, DNSSEC validation on the device requires caching. > > the question is if i gain aynthing doing it on the end-device If you need to ask this question I think you missed the whole point of DNSSEC. > have fun debugging DNS troubles of a road-warrior in your network > without realize that he brings his own DNS server Caching DNS is common on many OSs, it is nothing special really. > >> In conclusion, I don't percieve that a DNS cache in Fedora is a good > >> idea, as it solves few real world problems, and may in fact create > >> issues, mask issues and create a bad stigma about Fedora network > >> reliability. If it is to become available to users I would like: > > > > I believe you will need to re-think that in light of running a > > validating DNSSEC resolver on your laptop or servers. > > no Oh yeah, you have to. You may decide you do not like it. That is fine, but DNSSEC does change things slightly and, IMHO, for the better. > >> * DNS cache is not the default. It bust be enabled on a connection (IE > >> user's in case 1 can enable it if needed) Just to answer William too, I do not think you brought any evidence that this would not be a good default. On the contrary in base OS we've felt for a long time now the need for it. It is a pain to do without a decent cache, and nscd is not it! > >> * DNS cache should be able to be enabled from the NM Gui A way to toggle it on and off is not a bad idea, but I do not think it needs to be a requirement. Turning off the unbound service is not exactly difficult. > >> * DNS cache should be able to be flushed live from the NM Gui I totally agree there should be a way to flush the cache, I am not sure it makes sense to have it in the GUI, certainly nm-cli (or other command) should offer it. > >> * DNS cache should be flushed on route or interface state change. I do not see why, the only reason to flush a cache is when there is a DNS change (new interface, eg VPN coming up, or going away) > >> * If two interfaces are active, the default route DNS cache setting > >> takes precedence. This would break VPNs, which are often not the default route. What you want is to send arbitrary queries to the default DNS, and have forwarders per domain for special interfaces like VPNs (unless in the configuration you establish that all DNS traffic should go over the VPN when you connect). > > You cannot separate dns cache from DNSSEC. DNS caching is not a problem, > > it is a feature. If you don't want your records cached, use ttl=0 > > the cache already is running in my LAN for good reasons That's a different cache, however if you feel strongly you will be able to turn off the local caching dns server on your machines, at your option. > that DNS cache is pushed with DHCP Forwarders are pushed via DHCP, not caches. > that DNS cache already does DNSSEC validation Which is useless in the *general* case. You may think your physical security is perfect, that;s great, but for everybody else, trusting the network is not ok, that's why more an more people de[ploy TLS or GSSAPI in internal networks too. The era of the clear text trusted private network is coming to an end, whether you like it or not. > if you don't trust the network itself you are lost anyways Let me troll a bit, this is why you do all your banking without HTTPS ? :-) I am strongly in favor of a DNS cache on Fedora, and I would even seriously consider any proposal of making it the default on Fedora Server too. Regards, Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 2014-04-12 at 17:46 -0700, Andrew Lutomirski wrote: > On Sat, Apr 12, 2014 at 5:18 PM, William Brown > wrote: > > > >> Now can we go back to actually discussion technical arguments again? > > > > Actually no. > > > > This whole thread has forgotten one major thing ... use cases. > > > > Proposal is to add a local caching DNS server to fedora systems. This > > may or may not accept a DHCP provided forwarder(?). > > > > [snipped lots of entirely legitimate use cases] > > > > > Now, in all of these cases the system local DNS cache *must* forward to > > the local DNS server. You can't at the OS distinguish between any of > > these cases with just the DHCP record or lease. It is unreasonable to > > ask everyone to manually setup DNS on every network they join. You must > > have the forwarder set to the DNS provided by DHCP so that you can > > access the local network resources. You cannot suggest bypassing these. > > > > I don't think anyone is suggesting bypassing these. That is, all of > your use cases *will still work*, possibly better than they do now, > with a systemwide resolver. A system wide resolver I am not opposed to. I am against a system wide *caching* resolver. > > > > > Case 1: The user doesn't know much about DNS. the ISP might be reliable > > or unreliable. If we assume as discussed that the cache is flushed on > > network change, they will have an empty cache. With a good, ISP, they > > will get consistent answers to queries, and there is no point to having > > the cache. > > There are two good reasons for the cache: > > 1. DNSSEC. Trusting the AD bit from the ISP is wrong. > > 2. Caching. It's a lot better to have a correct systemwide cache than > a bunch of per-application crappy caches. In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a cache is a severe detriment. > > > > > Case 3: This user does understand DNS, and they don't need DNS cache. > > They have bind / named setup, and they would like to rely on that > > instead. When they change records in their local zones, they don't want > > to have to flush caches etc. If their ISP is unreliable, or their own > > DNS is unreliable, a DNS cache will potentially mask this issue delaying > > them from noticing / solving the problem. > > That's what an extremely short TTL is for. Also, anyone relying on > local clients not caching when TTL is already terminally screwed. > Consider that Firefox, Chromium, Windows, and I suspect Mac OS and > Android have caches. The fact that Linux command line tools have no > cache right now is not a feature. I disable the DNS cache in firefox with developer tools. Additionally, a short TTL is good, for this situation, but it can't fix everything. Short ttls really rely on every layer of the stack actually not messing with this. However that's another issue. > > > > > Case 8: Vpns are a bit unreliable, and have relatively high(ish) > > latency. But mostly they are quite good, ie openvpn. > > Hah. Openvpn screws up its own internal DNS cache on a regular basis > for me. This is a common cause of Ctrl-C. > > --Andy I don't use the OpenVPN dns cache. -- William Brown signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On 2014-04-12 16:12 (GMT-0400) Simo Sorce composed: On Sat, 2014-04-12 at 13:11 -0400, Felix Miata wrote: On 2014-04-12 11:01 (GMT-0400) Paul Wouters composed: > Chuck Anderson wrote: >> Maybe we should set the file to be immutable after setting it to 127.0.0.1: >> chattr +i /etc/resolv.conf > That is the trick currently used by dnssec-triggerd to prevent other > applications from messing with that file. I've been doing that myself for years on installations that think my ethernet-only non-wireless LAN host connections need "managing" by NetworkManager, Resolvconf, Wicked or anything else that came along to automagically mis-configure it. So you've gone out of your way to run a daemon but prevent it from working as configured, instead of just reconfiguring it to do what you need. What daemon did I go out of my way to run? I have Network Manager and it is extremely simple to configure it to keep fixed DNS Servers as well as have static addresses for ethernet interfaces. Simple without X running, where I normally perform my elementary configuration chores in an OFM? When I install, I install minimal, so there is no X available to tweak the installer's defaults. I find that today, except extremely rare case, all that people that complain about network management tools interfering are people that never tried or tried once *years* ago and never checked again. Maybe so, but then some of us don't need our networks "managed", only just configured at installation time, after which they are left untouched for the remaining lifetime of the installation. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
Am 13.04.2014 03:07, schrieb Paul Wouters: > On Sun, 13 Apr 2014, William Brown wrote: >> When they change records in their local zones, they don't want >> to have to flush caches etc. If their ISP is unreliable, or their own >> DNS is unreliable, a DNS cache will potentially mask this issue delaying >> them from noticing / solving the problem. > > This is becoming really contrived. Again, if you think this is a real > scenario (I don't think it is) than you could run unbound with ttl=0 i would run BIND and not unbound in any case and now? would you pull me unbound as dependency? > But a requirement of automagically understanding what a local zone is > and automagically understanding when a remote authoritative dns server > changes data, and not willing to enforce that with ttl=0, and using > that as argument why any solution of unbound to provide a security > feature (DNSSEC) is getting a little unrealistic. If you want your > laptop to start validating TLSA and SSHP and OPENPGPKEY records, you > need DNSSEC validation on the device. The question should be "how do you > change your network requirements to meet that goal". Yes, enforcing > security comes at a price. boah it is *not* a security feature having a local resolver which may bypass my DHCP provided DNS which may be the only one with the correct DNS view if you ask him anyways the result can't be more secure than aksing him directly, if not your breaking real world in other words: if you are in a untrustable LAN you can not make it more trustable without good changes to break things in trustable ones > Let me use your scenario based on TLS. You want to be able to change > your TLS certificates and the private CA you regenerate at any time, > without any browser on your network ever giving you a popup warning. > You know you cannot ask this - it goes against the security model. The > same applies for DNS with DNSSEC. The security demands we need to do > validation and caching and we should try to make that as flexible and > painless as possible uhm no - there is a CA signed root zone -> signed TLD -> signed domain and if you believe that in a not trustable network you don't know if you get the signing informations at all - fine, but you hardly an enforce that with a local software if i control the network i control the whle traffic and without your own satellite link you can't change that >> Case 4, 5, 6 and 7: DNS cache, again, isn't needed. > > Again, DNSSEC validation on the device requires caching. the question is if i gain aynthing doing it on the end-device >> The infrastructure >> is well setup, and caching is done by the business servers. DNS outages >> at the business level, mean there are other issues and they will likely >> be resolved quickly. You don't want to reboot / reset interfaces for >> each time you make a change or as the first result of an issue (Again, >> this would give fedora a bad name). DNS caching may mask a bigger >> problem. > > I don't really understand this paragraph. have fun debugging DNS troubles of a road-warrior in your network without realize that he brings his own DNS server >> In conclusion, I don't percieve that a DNS cache in Fedora is a good >> idea, as it solves few real world problems, and may in fact create >> issues, mask issues and create a bad stigma about Fedora network >> reliability. If it is to become available to users I would like: > > I believe you will need to re-think that in light of running a > validating DNSSEC resolver on your laptop or servers. no >> * DNS cache is not the default. It bust be enabled on a connection (IE >> user's in case 1 can enable it if needed) >> * DNS cache should be able to be enabled from the NM Gui >> * DNS cache should be able to be flushed live from the NM Gui >> * DNS cache should be flushed on route or interface state change. >> * If two interfaces are active, the default route DNS cache setting >> takes precedence. > > You cannot separate dns cache from DNSSEC. DNS caching is not a problem, > it is a feature. If you don't want your records cached, use ttl=0 the cache already is running in my LAN for good reasons that DNS cache is pushed with DHCP that DNS cache already does DNSSEC validation if you don't trust the network itself you are lost anyways signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sun, 13 Apr 2014, William Brown wrote: Now can we go back to actually discussion technical arguments again? Actually no. This whole thread has forgotten one major thing ... use cases. That was in response to someone using appeal of authority statements, not factual discussions. Proposal is to add a local caching DNS server to fedora systems. This may or may not accept a DHCP provided forwarder(?). Yes. It depends on the "trustworthiness" of the network and or preconfiguration of some of your own networks you join. Case 1: Standard home user. Has little knowledge of DNS, and a router provided by their ISP. DHCP provides the laptop with the DNS ip of the router, which then acts as a forwarder to the ISP Works reasonably well with unbound+dnssec-triger, could use better NM integration for captive portals. Case 2: Moderate home user. They have a little knowledge of DNS, and have setup a system like OpenWRT or gargoyle on their router. They have their own zone, .local . This means that their DHCP provides the DNS ip of the router to clients. Same if their wifi is closed (eg WPA2), will need an exception in NM if their wifi is open for the .local forward. Case 3: Power home user. They likely have their own fedora router server or some other system setup. They run their own bind / named instance on their network, with their own zone or two. They have DHCP setup, perhaps to use DDNS updates to named. Same as above. Case 4: Small business workstation. Likely the small business, like the power home user, has their own name server. It may be Windows DNS from AD, or bind. Same as above. Case 5: Medium / Large business workstation. It's nearly guaranteed that the business runs their own zones. They have their own extensive, well organised bind / named setup. When connecting to their LAN or secure wifi, same as above for one one forwarding zone. Multiple forwarding zones would need to be configured. It if is an enterprise, they might need their corporate CAs as well as their zones configuration, so a corporate rpm package would make sense. Case 6: Fedora server in a small business: Same as the workstation, likely AD or bind in the office. Same as previous Case 7: Fedora server in the large business. Same as the workstation. Same as previous Case 8: Road warrior to the power home, small business, or large business. Uses VPN, and needs access to the DNS provided by the push dhcp / dns options from their vpn tunnel. Same, already works if you only need the one domain that is negotiated via the VPN (eg the IKE XAUTH domain). Now, in all of these cases the system local DNS cache *must* forward to the local DNS server. You can't at the OS distinguish between any of these cases with just the DHCP record or lease. It is unreasonable to ask everyone to manually setup DNS on every network they join. You must have the forwarder set to the DNS provided by DHCP so that you can access the local network resources. You cannot suggest bypassing these. We are not suggesting that for LAN or secure wifi. In those cases the forward will be added. However, you don' want those forwards for open wifi or else I can bring up "linksys" push you a forward for your internal.domain.com and mislead you into thinking you would be going over your VPN. Case 1: The user doesn't know much about DNS. the ISP might be reliable or unreliable. If we assume as discussed that the cache is flushed on network change, they will have an empty cache. The cache is never fully flushed. It is only flushed for the domain obtained via DHCP or VPN, because those entries can change. They are not changed for anything else. If the upstream ISP could have spoofed them, so be it - the publisher of the domains could have used DNSSEC to prevent that from happening. With a good, ISP, they will get consistent answers to queries, and there is no point to having the cache. If the ISP is unreliable, they will get records that are incorrect (See broken TTLs etc), There is no such things as "broken TTLs". And there is no modern nameserver that believes or honours TTLs for months. The unbound default is cache-max-ttl: 86400. Nothing will be cached for more than one day regardless of the TTL received. Again, if a publisher of a zone wants ISPs to keep their hands of their records, they should use DNSSEC and sign their zone. Case 2: The user does know a bit. But when they change name records they may not be able to solve why a workstation can't resolve names like other clients. While we could flush the entire cache on (dis)connect, I think that's rather drastic for this kind of odd use-case. If the user runs their own zone and their own records, they should know about DNS and TTLs. But even so, NM could offer an option to flush the DNS cache. Case 3: This user does understand DNS, and they don't need DNS cache. That depends. You need caching for DNSSEC validation, so really, every device needs a cache, unless you want to o
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 5:18 PM, William Brown wrote: > >> Now can we go back to actually discussion technical arguments again? > > Actually no. > > This whole thread has forgotten one major thing ... use cases. > > Proposal is to add a local caching DNS server to fedora systems. This > may or may not accept a DHCP provided forwarder(?). > [snipped lots of entirely legitimate use cases] > > Now, in all of these cases the system local DNS cache *must* forward to > the local DNS server. You can't at the OS distinguish between any of > these cases with just the DHCP record or lease. It is unreasonable to > ask everyone to manually setup DNS on every network they join. You must > have the forwarder set to the DNS provided by DHCP so that you can > access the local network resources. You cannot suggest bypassing these. > I don't think anyone is suggesting bypassing these. That is, all of your use cases *will still work*, possibly better than they do now, with a systemwide resolver. > > Case 1: The user doesn't know much about DNS. the ISP might be reliable > or unreliable. If we assume as discussed that the cache is flushed on > network change, they will have an empty cache. With a good, ISP, they > will get consistent answers to queries, and there is no point to having > the cache. There are two good reasons for the cache: 1. DNSSEC. Trusting the AD bit from the ISP is wrong. 2. Caching. It's a lot better to have a correct systemwide cache than a bunch of per-application crappy caches. > > Case 3: This user does understand DNS, and they don't need DNS cache. > They have bind / named setup, and they would like to rely on that > instead. When they change records in their local zones, they don't want > to have to flush caches etc. If their ISP is unreliable, or their own > DNS is unreliable, a DNS cache will potentially mask this issue delaying > them from noticing / solving the problem. That's what an extremely short TTL is for. Also, anyone relying on local clients not caching when TTL is already terminally screwed. Consider that Firefox, Chromium, Windows, and I suspect Mac OS and Android have caches. The fact that Linux command line tools have no cache right now is not a feature. > > Case 8: Vpns are a bit unreliable, and have relatively high(ish) > latency. But mostly they are quite good, ie openvpn. Hah. Openvpn screws up its own internal DNS cache on a regular basis for me. This is a common cause of Ctrl-C. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> Now can we go back to actually discussion technical arguments again? Actually no. This whole thread has forgotten one major thing ... use cases. Proposal is to add a local caching DNS server to fedora systems. This may or may not accept a DHCP provided forwarder(?). Case 1: Standard home user. Has little knowledge of DNS, and a router provided by their ISP. DHCP provides the laptop with the DNS ip of the router, which then acts as a forwarder to the ISP Case 2: Moderate home user. They have a little knowledge of DNS, and have setup a system like OpenWRT or gargoyle on their router. They have their own zone, .local . This means that their DHCP provides the DNS ip of the router to clients. Case 3: Power home user. They likely have their own fedora router server or some other system setup. They run their own bind / named instance on their network, with their own zone or two. They have DHCP setup, perhaps to use DDNS updates to named. Case 4: Small business workstation. Likely the small business, like the power home user, has their own name server. It may be Windows DNS from AD, or bind. Case 5: Medium / Large business workstation. It's nearly guaranteed that the business runs their own zones. They have their own extensive, well organised bind / named setup. Case 6: Fedora server in a small business: Same as the workstation, likely AD or bind in the office. Case 7: Fedora server in the large business. Same as the workstation. Case 8: Road warrior to the power home, small business, or large business. Uses VPN, and needs access to the DNS provided by the push dhcp / dns options from their vpn tunnel. Now, in all of these cases the system local DNS cache *must* forward to the local DNS server. You can't at the OS distinguish between any of these cases with just the DHCP record or lease. It is unreasonable to ask everyone to manually setup DNS on every network they join. You must have the forwarder set to the DNS provided by DHCP so that you can access the local network resources. You cannot suggest bypassing these. Case 1: The user doesn't know much about DNS. the ISP might be reliable or unreliable. If we assume as discussed that the cache is flushed on network change, they will have an empty cache. With a good, ISP, they will get consistent answers to queries, and there is no point to having the cache. If the ISP is unreliable, they will get records that are incorrect (See broken TTLs etc), or no record at all. The cache will only help once a record has been returned once, and will only aleviate pain "later" in the session. So DNS caching *may* help here. Case 2: The user does know a bit. But when they change name records they may not be able to solve why a workstation can't resolve names like other clients. We don't want to give Fedora the same name as Windows, where you need to turn on/off the network interface all the time to solve issues (to flush the DNS cache). In this example, the user wants their router to (maybe) cache the records, and to absolve this from clients. Case 3: This user does understand DNS, and they don't need DNS cache. They have bind / named setup, and they would like to rely on that instead. When they change records in their local zones, they don't want to have to flush caches etc. If their ISP is unreliable, or their own DNS is unreliable, a DNS cache will potentially mask this issue delaying them from noticing / solving the problem. Case 4, 5, 6 and 7: DNS cache, again, isn't needed. The infrastructure is well setup, and caching is done by the business servers. DNS outages at the business level, mean there are other issues and they will likely be resolved quickly. You don't want to reboot / reset interfaces for each time you make a change or as the first result of an issue (Again, this would give fedora a bad name). DNS caching may mask a bigger problem. Case 8: Vpns are a bit unreliable, and have relatively high(ish) latency. But mostly they are quite good, ie openvpn. DNS cache *might* help here in case of traffic loss. Again, this would be masking a greater issue though, and could be better solved with TCP dns queries rather than UDP. Only case 1 and 8 have real reasons to use a local OS dns cache. However, you can not distinguish these from the other cases at a network level. IE you couldn't make the cache easily enabled / disabled based on some network parameter. Additionally, case 1 is only needed in the situation that you have a low quality connection, or a low quality ISP forwarder. Both of these are issues you should take up with your ISP, and shouldn't be solved by Fedora. Case 8 with the VPN, is inherently hard to fix. VPN reliability is always improving and I think it's becoming less of an issue. I would also say it's a "rarer" use case than the others. In conclusion, I don't percieve that a DNS cache in Fedora is a good idea, as it solves few real world problems, and may in fact create issues, mask issues and create a bad stigma a
Re: default local DNS caching name server
On Sat, 2014-04-12 at 13:11 -0400, Felix Miata wrote: > On 2014-04-12 11:01 (GMT-0400) Paul Wouters composed: > > > Chuck Anderson wrote: > > >> Maybe we should set the file to be immutable after setting it to 127.0.0.1: > > >> chattr +i /etc/resolv.conf > > > That is the trick currently used by dnssec-triggerd to prevent other > > applications from messing with that file. > > I've been doing that myself for years on installations that think my > ethernet-only non-wireless LAN host connections need "managing" by > NetworkManager, Resolvconf, Wicked or anything else that came along to > automagically mis-configure it. So you've gone out of your way to run a daemon but prevent it from working as configured, instead of just reconfiguring it to do what you need. I have Network Manager and it is extremely simple to configure it to keep fixed DNS Servers as well as have static addresses for ethernet interfaces. I find that today, except extremely rare case, all that people that complain about network management tools interfering are people that never tried or tried once *years* ago and never checked again. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 2014-04-12 at 13:04 -0400, Chuck Anderson wrote: > On Sat, Apr 12, 2014 at 12:06:23PM -0400, Paul Wouters wrote: > > On Sat, 12 Apr 2014, Chuck Anderson wrote: > > > > >Okay, so here is where you and I differ then. We need a solution to > > >run everywhere, on every system, in every use case. > > > > Sounds like wanting ponies? Obviously I fully agree with a solution that > > works everywhere, all the time, for everyone, however the want it :) > > > > > The local DNS > > >daemon (note that I didn't say "cache" this time) should be a part of > > >the Base OS like init/systemd is. It should be small, unobtrusive, > > >and do very little, namely the one thing we need: handle failover > > >between multiple DNS servers. I would use the term "DNS proxy" but > > >that term is too overloaded with other connotations and preconceived > > >ideas. > > > > Handling failover requires keeping state of previous queries and > > outstanding requests to determine which servers are bad or not. Mind > > you, unbound allows you to set a max TTL on any record received using > > cache-max-ttl=0, so you can very easilly implement this idea. I think > > it is a bad idea, because your solution violates your own principle > > above: it interferes with my use case of optimising DNS caches, reducing > > unneccessary latency, and doing things like pre-fetching of low TTL > > records. > > Of course there would be /some/ state kept. It just wouldn't cache > the data, it would only use the state of recent queries and response > times to determine if that resolver was dead and start sending those > queries to another resolver. It would basically do exactly what > glibc's stub resolver does now, but ONCE for the entire system rather > than having each process do that independently. I would want this > daemon to be as lightweight as possible to minimize any interference > with optimising DNS caches, latency, etc. and so that it could be used > everywhere, just like systemd is used on all Fedora systems and some > form of "init" is used on all Linux systems. > > Another way to think of this is to separate out the built-in logic in > unbound/BIND/dnsmasq/etc. that determines when an authoritative server > is dead and apply it to all queries that are made by glibc's stub > resolver. Or separate out the logic that glibc uses to determine when > a nameserver in /etc/resolv.conf is dead and make that a system-wide > daemon. You can do this today, just write a nsswitch module to handle the host database and connect to it via a pipe from all processes. > > In DNS, the publisher of data tells you how long the data should be valid > > for. If they want the record not to be cached at all, they can set the TTL > > to 0. Why should we deploy a daemon that does not provide the very useful > > feature of caching in general (especially when doing DNSSEC validation) > > when people who wish to not get cached already have a means out, publish > > records with TTL=0? If you want to be Akamai, you can! > > Because things get messy once you start caching on the end-user > system. Citation please ? What kind of messy ? If you properly handle TTLs what gets messed up ? *especially* if unbound is configured to automatically flush caches when you change networks. > Sure, you can optionally have that messiness (and I'd argue > that for Fedora Workstation that would be a sane default) but for > Fedora Server I think it is too heavyweight of a solution to run > everywhere, and you agreed that running this in VMs is probably not > desired. > > If the lightweight dnslookupd process is configured to forward the > request to a local unbound+dnssec-triggerd, then everything from that > point will work in the same way it does today with local caching, TTL > handling, DNSSEC, etc. But that should be /optional/. I'm arguing > that dnslookupd should be on by default everywhere. Can you substantiate what is lightweight for you ? I have unbound running on my machine and it is basically unnoticeable. The resident memory is 15MiB, with the data and all right around the same size of other similar daemons like polkitd system-journald dhclient dbus-daemon, all stuff you already run your servers and I have never heard anybody call them *heavy* weight. > > >dnslookupd keeps track of up/down DNS servers via some health check > > >mechanism, and switches between them appropriately. > > > > I tend to call heartbeats/keepalives "make deads". They often do the > > opposite. Why invent a whole new health check protocol when you can > > simple send DNS queries and use strategies to prefer the nearest/fastest > > servers already. These kind of selection/preference protocols are part > > of any decent DNS implementation. There is no need to re-invent the > > wheel. > > It doesn't need to do active heartbeats--it could passively watch > queries/responses that it is forwarding to the resolver and decide > based on that if a server is dead and stop querying it until
Re: default local DNS caching name server
On 2014-04-12 11:01 (GMT-0400) Paul Wouters composed: Chuck Anderson wrote: Maybe we should set the file to be immutable after setting it to 127.0.0.1: chattr +i /etc/resolv.conf That is the trick currently used by dnssec-triggerd to prevent other applications from messing with that file. I've been doing that myself for years on installations that think my ethernet-only non-wireless LAN host connections need "managing" by NetworkManager, Resolvconf, Wicked or anything else that came along to automagically mis-configure it. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 12:06:23PM -0400, Paul Wouters wrote: > On Sat, 12 Apr 2014, Chuck Anderson wrote: > > >Okay, so here is where you and I differ then. We need a solution to > >run everywhere, on every system, in every use case. > > Sounds like wanting ponies? Obviously I fully agree with a solution that > works everywhere, all the time, for everyone, however the want it :) > > > The local DNS > >daemon (note that I didn't say "cache" this time) should be a part of > >the Base OS like init/systemd is. It should be small, unobtrusive, > >and do very little, namely the one thing we need: handle failover > >between multiple DNS servers. I would use the term "DNS proxy" but > >that term is too overloaded with other connotations and preconceived > >ideas. > > Handling failover requires keeping state of previous queries and > outstanding requests to determine which servers are bad or not. Mind > you, unbound allows you to set a max TTL on any record received using > cache-max-ttl=0, so you can very easilly implement this idea. I think > it is a bad idea, because your solution violates your own principle > above: it interferes with my use case of optimising DNS caches, reducing > unneccessary latency, and doing things like pre-fetching of low TTL > records. Of course there would be /some/ state kept. It just wouldn't cache the data, it would only use the state of recent queries and response times to determine if that resolver was dead and start sending those queries to another resolver. It would basically do exactly what glibc's stub resolver does now, but ONCE for the entire system rather than having each process do that independently. I would want this daemon to be as lightweight as possible to minimize any interference with optimising DNS caches, latency, etc. and so that it could be used everywhere, just like systemd is used on all Fedora systems and some form of "init" is used on all Linux systems. Another way to think of this is to separate out the built-in logic in unbound/BIND/dnsmasq/etc. that determines when an authoritative server is dead and apply it to all queries that are made by glibc's stub resolver. Or separate out the logic that glibc uses to determine when a nameserver in /etc/resolv.conf is dead and make that a system-wide daemon. > In DNS, the publisher of data tells you how long the data should be valid > for. If they want the record not to be cached at all, they can set the TTL > to 0. Why should we deploy a daemon that does not provide the very useful > feature of caching in general (especially when doing DNSSEC validation) > when people who wish to not get cached already have a means out, publish > records with TTL=0? If you want to be Akamai, you can! Because things get messy once you start caching on the end-user system. Sure, you can optionally have that messiness (and I'd argue that for Fedora Workstation that would be a sane default) but for Fedora Server I think it is too heavyweight of a solution to run everywhere, and you agreed that running this in VMs is probably not desired. If the lightweight dnslookupd process is configured to forward the request to a local unbound+dnssec-triggerd, then everything from that point will work in the same way it does today with local caching, TTL handling, DNSSEC, etc. But that should be /optional/. I'm arguing that dnslookupd should be on by default everywhere. > >dnslookupd keeps track of up/down DNS servers via some health check > >mechanism, and switches between them appropriately. > > I tend to call heartbeats/keepalives "make deads". They often do the > opposite. Why invent a whole new health check protocol when you can > simple send DNS queries and use strategies to prefer the nearest/fastest > servers already. These kind of selection/preference protocols are part > of any decent DNS implementation. There is no need to re-invent the > wheel. It doesn't need to do active heartbeats--it could passively watch queries/responses that it is forwarding to the resolver and decide based on that if a server is dead and stop querying it until the next one fails, etc. just like glibc does today. For the use cases you desire with full caching and DNSSEC, dnslookupd shouldn't get in the way. All applications/glibc would query 127.0.0.1, which would immediately forward all those requests to the local unbound+dnssec-triggerd setup. Dnslookupd would only take action if unbound died for some reason (and if there was an alternate DNS resolver to switch to). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 12 Apr 2014, Chuck Anderson wrote: Okay, so here is where you and I differ then. We need a solution to run everywhere, on every system, in every use case. Sounds like wanting ponies? Obviously I fully agree with a solution that works everywhere, all the time, for everyone, however the want it :) The local DNS daemon (note that I didn't say "cache" this time) should be a part of the Base OS like init/systemd is. It should be small, unobtrusive, and do very little, namely the one thing we need: handle failover between multiple DNS servers. I would use the term "DNS proxy" but that term is too overloaded with other connotations and preconceived ideas. Handling failover requires keeping state of previous queries and outstanding requests to determine which servers are bad or not. Mind you, unbound allows you to set a max TTL on any record received using cache-max-ttl=0, so you can very easilly implement this idea. I think it is a bad idea, because your solution violates your own principle above: it interferes with my use case of optimising DNS caches, reducing unneccessary latency, and doing things like pre-fetching of low TTL records. In DNS, the publisher of data tells you how long the data should be valid for. If they want the record not to be cached at all, they can set the TTL to 0. Why should we deploy a daemon that does not provide the very useful feature of caching in general (especially when doing DNSSEC validation) when people who wish to not get cached already have a means out, publish records with TTL=0? If you want to be Akamai, you can! dnslookupd keeps track of up/down DNS servers via some health check mechanism, and switches between them appropriately. I tend to call heartbeats/keepalives "make deads". They often do the opposite. Why invent a whole new health check protocol when you can simple send DNS queries and use strategies to prefer the nearest/fastest servers already. These kind of selection/preference protocols are part of any decent DNS implementation. There is no need to re-invent the wheel. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 04:40:50PM +0100, Richard W.M. Jones wrote: > On Sat, Apr 12, 2014 at 11:01:20AM -0400, Paul Wouters wrote: > > On Sat, 12 Apr 2014, Chuck Anderson wrote: > > >Maybe we should set the file to be immutable after setting it to 127.0.0.1: > > > > > >chattr +i /etc/resolv.conf > > > > That is the trick currently used by dnssec-triggerd to prevent other > > applications from messing with that file. > > Oh crap, that means I'm going to need a "really really don't touch > this file" flag, perhaps a one-way flag that can never be un-set. > > I'm already setting chattr +i /etc/resolv.conf to stop anything > touching the file, and I don't want apps to mess with that flag (or > the file). Bind mount the file to a read-only filesystem? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 11:05:21AM -0400, Paul Wouters wrote: > On Sat, 12 Apr 2014, Reindl Harald wrote: > > >nonsense - there are so much ISP nameservers broken out there > >responding with wildcards and so on that you can not trust them > >and you will realize that if not before after you started to run > >a production mailserver which relies on NXDOMAIN responses for > >proper operations > > That's not what the http://atlas.ripe.net/ data set indicates. Your > story seems anecdotal and incidental. > > Yes, there are a few bad players out there (like Rogers in Canada) but > those are in a minority. That said, I agree that using unbound on your > servers will reduce upstream DNS outage problems on your servers. I > wouldn't run unbound on every VM though. Okay, so here is where you and I differ then. We need a solution to run everywhere, on every system, in every use case. The local DNS daemon (note that I didn't say "cache" this time) should be a part of the Base OS like init/systemd is. It should be small, unobtrusive, and do very little, namely the one thing we need: handle failover between multiple DNS servers. I would use the term "DNS proxy" but that term is too overloaded with other connotations and preconceived ideas. All the other stuff is great, but it should run at a higher level and perhaps be optional like you say. You may not want DNSSEC validation in every VM, or indeed on every server in a corporate datacenter. But you still do need the local DNS daemon to handle failover ONCE for the entire system, rather than the way glibc does it now PER PROCESS. I omitted "cache" from my description of the local DNS daemon this time around, because after thinking about it more, once you introduce a cache you have to deal with flushing that cache and that complicates things perhaps more than people are willing to accept. Having a cache is not required to handle the most basic failover functionality. This local non-caching, non-recursive stub DNS daemon could sit in front of, behind, or beside (in place of) other optional full DNSSEC/caching/VPN-aware solutions. For the purposes of this example, lets call this theoretical daemon "dnslookupd": resolv.conf is configured with 127.0.0.1. dnslookupd listens on 127.0.0.1:53. dnslookupd is configured with one or more DNS servers (which could be local daemon(s) on other loopback addresses or ports). dnslookupd keeps track of up/down DNS servers via some health check mechanism, and switches between them appropriately. dnslookupd does not cache any results--it simply forwards the queries to one chosen DNS server. dnslookupd provides an API for other components to configure the list/order of DNS servers (perhaps dbus). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 12 Apr 2014, Richard W.M. Jones wrote: chattr +i /etc/resolv.conf That is the trick currently used by dnssec-triggerd to prevent other applications from messing with that file. Oh crap, that means I'm going to need a "really really don't touch this file" flag, perhaps a one-way flag that can never be un-set. I'm already setting chattr +i /etc/resolv.conf to stop anything touching the file, and I don't want apps to mess with that flag (or the file). Which is we need native NM integration, and applications telling NM what to do with resolv.conf so only NM modifies it (and provides with overrides to accomodate your "hardcoded" version). Preferably enforced by SElinux. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 11:01:20AM -0400, Paul Wouters wrote: > On Sat, 12 Apr 2014, Chuck Anderson wrote: > >Maybe we should set the file to be immutable after setting it to 127.0.0.1: > > > >chattr +i /etc/resolv.conf > > That is the trick currently used by dnssec-triggerd to prevent other > applications from messing with that file. Oh crap, that means I'm going to need a "really really don't touch this file" flag, perhaps a one-way flag that can never be un-set. I'm already setting chattr +i /etc/resolv.conf to stop anything touching the file, and I don't want apps to mess with that flag (or the file). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
Am 12.04.2014 17:21, schrieb Paul Wouters: > On Sat, 12 Apr 2014, Reindl Harald wrote: > >>> That's wrong. a DNS server can use a forwareder for some or all of its >>> recursive queries. unbound+dnssec-triggerd mostly cause unbound to do >>> full recursion but using the ISP nameserver as forward for all queries. >> >> oh no - please try to understand what recursion means in case of DNS >> >> may i suggest to read some docs because if i talk about DNS as one >> who maintains 600 domains as DNS provider as well as Registry for >> the .at domain and implemented DNS admin-backends years ago i know >> what i am talking about > > If we are going to do appeals to authority for making arguments, I've > been doing DNSSEC since 2001, ran an ISP between 1995 and 2005 that had > 500+ domains, have pending DNS RFC drafts out there, am acknowledged > on many more DNS RFCs published, am a member of a global DNS incident > response team, member of DNS-OARC, implemented a failover dual-software > dual-setup multi-local DNSSEC signed for a TLD larger that .at praised > by the entire DNS industry, performed DNS outage post-mortem at one of > Canada's largest banks and was one of ten ICANN newGTLD Registry Services > panel members evaluting the 1500 new TLD submissions for their technical > implementations of DNS and Registry Services. I think I know what > recursion means. > > Now can we go back to actually discussion technical arguments again? than stop repsond with "That's wrong" if i tell someone forwarding != recursion because you should know it better and use correct terms signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
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
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 12 Apr 2014, Reindl Harald wrote: That's wrong. a DNS server can use a forwareder for some or all of its recursive queries. unbound+dnssec-triggerd mostly cause unbound to do full recursion but using the ISP nameserver as forward for all queries. oh no - please try to understand what recursion means in case of DNS may i suggest to read some docs because if i talk about DNS as one who maintains 600 domains as DNS provider as well as Registry for the .at domain and implemented DNS admin-backends years ago i know what i am talking about If we are going to do appeals to authority for making arguments, I've been doing DNSSEC since 2001, ran an ISP between 1995 and 2005 that had 500+ domains, have pending DNS RFC drafts out there, am acknowledged on many more DNS RFCs published, am a member of a global DNS incident response team, member of DNS-OARC, implemented a failover dual-software dual-setup multi-local DNSSEC signed for a TLD larger that .at praised by the entire DNS industry, performed DNS outage post-mortem at one of Canada's largest banks and was one of ten ICANN newGTLD Registry Services panel members evaluting the 1500 new TLD submissions for their technical implementations of DNS and Registry Services. I think I know what recursion means. Now can we go back to actually discussion technical arguments again? Thanks. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
Am 12.04.2014 17:05, schrieb Paul Wouters: > On Sat, 12 Apr 2014, Reindl Harald wrote: > >> nonsense - there are so much ISP nameservers broken out there >> responding with wildcards and so on that you can not trust them >> and you will realize that if not before after you started to run >> a production mailserver which relies on NXDOMAIN responses for >> proper operations > > That's not what the http://atlas.ripe.net/ data set indicates. Your > story seems anecdotal and incidental. if you call the year 2012 anecdotal then yes > Yes, there are a few bad players out there (like Rogers in Canada) but > those are in a minority it is not a matter of bad players, it is a matter of stupid admins on ISP sides - the case of our server was the largest ISP here and they simply had bugs in der load-balcing resulting in random results (current and outdated) from the same nameserver IP another one was also a large ISP which started 2013 to give that wrong answers for our ipv4 address in 2013 because they fucked up their DNS due try to implement ipv6 in both cases i know for sure what happened at the ISP note that the change was done in 2011 and we are even the GLUE record another big player at that time was OpenDNS sicne there are not too much DNS servers of ISP answering to non customer ip addresses i found around 50 public nameservers all over the world and 15 of them where wrong after more than 7 months - yes it is a minority because it's below 50% but *way too much* for such a critical service like DNS and here i did not talk a single time about overloaded and not responding IPS DNS again and again - we had many years massive troubles to access websites and it was always "could not be found" in Firefox which means no DNS answer - guess what - after no longer using forwarders nobody has seen that message again signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
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?
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
[...]
if [ -n "$(pidof unbound)" ]; then
echo "flushing local nameserver of ${PLUTO_PEER_DOMAIN_INFO}"
/usr/sbin/unbound-control forward_remove ${PLUTO_PEER_DOMAIN_INFO}
/usr/sbin/unbound-control flush_zone ${PLUTO_PEER_DOMAIN_INFO}
/usr/sbin/unbound-control flush_requestlist
return 0
fi
It even has fallbacks for when not running unbound to do this via
editing /etc/resolv.conf - obviously not as preferred as running
unbound, but still supported.
Paul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 12 Apr 2014, Chuck Anderson wrote: I don't disagree that there is lots of broken DNS out there. But realistically, we still need to default to using the DHCP-provided DNS servers as forwarders because there are unfortunately lots of circumstances where this is required to resolve corporate DNS names or to allow captive portals to work. If the local caching resolver is intelligent enough, it can handle the common use cases (corporate DNS resolution, VPN into corporate, captive portals) and work around the common failure modes (automatic cache flushing, switching to iterative mode to bypass upstream nameservers when necessary, using both the upstream nameservers AND iterative queries and combining the results) for us. What we cannot do is have the default be to bypass the upstream DNS resolvers without some way to handle the above cases. correct, which is why Anaconda should configure the DNS server that comes in via kickstart or administrator as a forwarder into unbound. It is one of the modifications required for this feature. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 12 Apr 2014, Reindl Harald wrote: nonsense - there are so much ISP nameservers broken out there responding with wildcards and so on that you can not trust them and you will realize that if not before after you started to run a production mailserver which relies on NXDOMAIN responses for proper operations That's not what the http://atlas.ripe.net/ data set indicates. Your story seems anecdotal and incidental. Yes, there are a few bad players out there (like Rogers in Canada) but those are in a minority. That said, I agree that using unbound on your servers will reduce upstream DNS outage problems on your servers. I wouldn't run unbound on every VM though. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
Am 12.04.2014 16:55, schrieb Paul Wouters: > On Sat, 12 Apr 2014, Reindl Harald wrote: > >> a DNS server doing recursion don't ask any forwarder > > That's wrong. a DNS server can use a forwareder for some or all of its > recursive queries. unbound+dnssec-triggerd mostly cause unbound to do > full recursion but using the ISP nameserver as forward for all queries. oh no - please try to understand what recursion means in case of DNS may i suggest to read some docs because if i talk about DNS as one who maintains 600 domains as DNS provider as well as Registry for the .at domain and implemented DNS admin-backends years ago i know what i am talking about recursion is by definition * ask the root server for example.com * answer of the root is "dunno, but you can ask xxx for .com" * your DNS asks xxx for example.com * answer of xxx is "dunno, but you can ask ns1.whoever.tld for example.com" forwarding bypasses that and asks your ISP's or whatever configured nameserver and never the root, so no, you don't do recursion in that case, your forwarder may do or at least the last forwarder if the DNS you asking itself does forwarding too - but that's not your business then and you don't to recursion signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 12 Apr 2014, Chuck Anderson wrote: I'm proposing that /etc/resolv.conf is never re-written under any circumstances. A local caching resolver should ALWAYS be used and resolv.conf should ALWAYS say: nameserver 127.0.0.1 Cheers. That's a goal I share with you, but... All the "magic" for secure/insecure modes during NTP bootstrapping or captive portals has to happen inside unbound (or whatever caching resolver/forwarder is eventually chosen) and it should never be bypassed. Currently, to prevent unbound from either rejecting DNS lies or get polluted by accepting DNS lies, is "taken offline" by the system during hotspot signon. resolv.conf is rewritten to use the DHCP supplied nameservers to get past the portal. During this time, all applications are exposed to DNS lies. Once the captive portal is done, resolv.conf is changed back to 127.0.0.1 and unbound is "online" again protecting all applications. If the network is so bad this cannot work, and the user opts to remain "insecure", the vulnerable situation is continued. If the user opts to go "cache only", than resolv.conf is written as 127.0.0.1 but unbound is configured with 127.0.0.127 as forwarder, meaning no new DNS answers will ever come in. As I said in previous posts, the ideal situation to not mess with resolv.conf on the host is to have a disposable secure container get the "new network" before any application gets network, do the hotspot login, and throw away the container. In that case, resolv.conf on the host (not container) never has to be modified. Maybe we should set the file to be immutable after setting it to 127.0.0.1: chattr +i /etc/resolv.conf That is the trick currently used by dnssec-triggerd to prevent other applications from messing with that file. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 12 Apr 2014, Reindl Harald wrote: a DNS server doing recursion don't ask any forwarder That's wrong. a DNS server can use a forwareder for some or all of its recursive queries. unbound+dnssec-triggerd mostly cause unbound to do full recursion but using the ISP nameserver as forward for all queries. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 12 Apr 2014, William Brown wrote: I should clarify. I cache the record foo.work.com from the office, and it resolves differently externally. When I go home, it no longer resolves to the external IP as I'm using the internally acquired record from cache. This currently works for the VPN scenario. When you connect the VPN, and the VPN gives you a domain/nameservers, unbound is reconfigured on the fly with those nameservers as forwards. A cache flush is done on connecting/disconnecting from the VPN for the specified domain. Part of the new proposal for dealing with your scenario consists of two parts. - LAN and secured WIFI that return a search domain and nameserver IPs will be installed as forwaders in unbound. The current content and request_list will be flushed using unbound-control. - open WIFI will do the same only after the user has told NM this network is to be "trusted". The current content and request_list will be flushed using unbound-control. That should deal with flushing internal-only records when not internal and flushing external records when not external. If the internal domain is using DNSSEC, further configuration of a trust anchor override might be needed. This can be done in /etc/unbound/*.d/ directories (commented out examples are present). Possible, this directory structure can be replaced by integrated NM support that reconfigured unbound (or dnsmasq) based on the same information. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
Am 12.04.2014 16:16, schrieb Chuck Anderson: > On Sat, Apr 12, 2014 at 04:03:14PM +0200, Reindl Harald wrote: >> Am 12.04.2014 15:31, schrieb Chuck Anderson: >>> I disagree. You can still do DNSSEC validation with a local caching >>> resolver and configure that local resolver to forward all queries to >>> the ISP. That should be tried first, and only bypassed and become a >>> full interative recursive querier bypassing the ISP resolvers if that >>> fails. We need to respect the DNS caching infrastructure by default. >> >> nonsense - there are so much ISP nameservers broken out there >> responding with wildcards and so on that you can not trust them >> and you will realize that if not before after you started to run >> a production mailserver which relies on NXDOMAIN responses for >> proper operations > > I don't disagree that there is lots of broken DNS out there. But > realistically, we still need to default to using the DHCP-provided DNS > servers as forwarders because there are unfortunately lots of > circumstances where this is required to resolve corporate DNS names or > to allow captive portals to work. if you rely on that and are a road-wwarrior don't setup a local dns > If the local caching resolver is > intelligent enough, it can handle the common use cases (corporate DNS > resolution, VPN into corporate, captive portals) and work around the > common failure modes (automatic cache flushing, switching to iterative > mode to bypass upstream nameservers when necessary, using both the > upstream nameservers AND iterative queries and combining the results) > for us. oh no - go away with such ideas there is nothing like "intelligent" in case of a DNS resolver the only thing you achieve trying that is unpredictable behavior > What we cannot do is have the default be to bypass the upstream DNS > resolvers without some way to handle the above cases. If mainstream > operating systems started doing that by default, then corporate > networks, ISPs, captive portals etc. will probably start blocking DNS > to outside servers or redirecting port 53 to their own servers. In > fact some already do this. We don't want to escalate the arms race by > encouraging this behavior "we" should not do anything - because "we" don't have a clue about the network of the enduser - if he is a road-warrior then he needs to use DHCP provided nameservers, if he is a roadrunner and has at home VPN access to his company network he has to enter the DNS servers behind the VPN into his router / dhcp and after coming home all works as expected if the roadrunner has the VPN client directly on his machine, well then he needs to make a decision: * enter the company nameservers in /etc/resolv.conf and always use VPN * enter the company LAN hostnames in /etc/hosts to not rely on DNS at all * manually change /etc/resolv.conf whenever needed there is nothing to gain with trying auto-magic for sensible things like DNS signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 04:03:14PM +0200, Reindl Harald wrote: > > > Am 12.04.2014 15:31, schrieb Chuck Anderson: > > On Sat, Apr 12, 2014 at 02:09:19PM +0800, P J P wrote: > >>> On Saturday, 12 April 2014 11:11 AM, William Brown wrote: > >>> Say I have freshly installed my fedora system at home. I then boot it up > >>> and start to use it. My laptop is caching DNS results all the while from > >>> the "unreliable" ISP. > >>> > >>> I then go to work and suddenly things don't work. > >>> > >>> Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a > >>> complaint with your ISP. > >> > >> What, no! that was the case for having local cache and not forwarding > >> queries to the ISP's name servers at all. Because those are not reliable. > > > > I disagree. You can still do DNSSEC validation with a local caching > > resolver and configure that local resolver to forward all queries to > > the ISP. That should be tried first, and only bypassed and become a > > full interative recursive querier bypassing the ISP resolvers if that > > fails. We need to respect the DNS caching infrastructure by default. > > nonsense - there are so much ISP nameservers broken out there > responding with wildcards and so on that you can not trust them > and you will realize that if not before after you started to run > a production mailserver which relies on NXDOMAIN responses for > proper operations I don't disagree that there is lots of broken DNS out there. But realistically, we still need to default to using the DHCP-provided DNS servers as forwarders because there are unfortunately lots of circumstances where this is required to resolve corporate DNS names or to allow captive portals to work. If the local caching resolver is intelligent enough, it can handle the common use cases (corporate DNS resolution, VPN into corporate, captive portals) and work around the common failure modes (automatic cache flushing, switching to iterative mode to bypass upstream nameservers when necessary, using both the upstream nameservers AND iterative queries and combining the results) for us. What we cannot do is have the default be to bypass the upstream DNS resolvers without some way to handle the above cases. If mainstream operating systems started doing that by default, then corporate networks, ISPs, captive portals etc. will probably start blocking DNS to outside servers or redirecting port 53 to their own servers. In fact some already do this. We don't want to escalate the arms race by encouraging this behavior. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 09:38:03 -0400, Chuck Anderson wrote: You cannot rely on DNS2 and DNS3 to be queried UNLESS DNS1=127.0.0.1 fails to respond. This might be a way to mitigate failure of the local caching resolver process, but it is not a way to ensure the ability to resolve internal names from the corporate nameserver. The way to ensure the latter is to configure the local caching resolver to forward to the DHCP-provided nameservers rather than becoming a full iterative resolver. If they do spilt horizon DNS using a zone that can be found normally, things will still work. If they use zones that can't be found that way, then you can make an exception for that zone, but still use iteration for other stuff. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
Am 12.04.2014 15:31, schrieb Chuck Anderson: > On Sat, Apr 12, 2014 at 02:09:19PM +0800, P J P wrote: >>> On Saturday, 12 April 2014 11:11 AM, William Brown wrote: >>> Say I have freshly installed my fedora system at home. I then boot it up >>> and start to use it. My laptop is caching DNS results all the while from >>> the "unreliable" ISP. >>> >>> I then go to work and suddenly things don't work. >>> >>> Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a >>> complaint with your ISP. >> >> What, no! that was the case for having local cache and not forwarding >> queries to the ISP's name servers at all. Because those are not reliable. > > I disagree. You can still do DNSSEC validation with a local caching > resolver and configure that local resolver to forward all queries to > the ISP. That should be tried first, and only bypassed and become a > full interative recursive querier bypassing the ISP resolvers if that > fails. We need to respect the DNS caching infrastructure by default. nonsense - there are so much ISP nameservers broken out there responding with wildcards and so on that you can not trust them and you will realize that if not before after you started to run a production mailserver which relies on NXDOMAIN responses for proper operations there are also a lot of broken DNS servers in general not respecting the TTL - not so long ago we moved one of our servers into our datacenter, changed the TTL to 5 minutes two days before and *7 months* later the DNS of my private ISP answered randomly with the old and the new address other DNS servers out there answered after 7 months still with the old the most broken one just answered with *both* suggesting round robin to the client - problem: the old IP did no longer exist at all how i tested that? by google for public answering nameservers, ask all which i found with a script and finally asked the tech contact of the broken ones why they not start to hire someone with the skills for DNS signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 12:38:41PM +0930, William Brown wrote: > I agree with the goal to add DNSSEC (Despite it's flaws). However, a > caching DNS server can create many headaches without a number of > considerations. > > First, it should be easily possible to clear / invalidate the cache for > a GUI and CLI user. This isn't possible on windows for example, and is > why often they ask people to reboot computers in the first instance of > an issue or migration. Additionally, every time the interface state > changes from up/down, or the default route changes, the cache should be > cleared. Consider a user of a corporate network that serves both an > internal zone and an external zone. The user may enter or exit the > network, and cached records would continue to be served causing issue. > > Second, it can create issues as otherwise mentioned by "dodgy" hotspots. > They server a fake DNS record for all hosts that resolves to the > hostspot. When the client authenticates they begin to serve the real > records. If these records are cached, suddenly, the hotspot is now > unusable (Especially if they don't set a TTL of say 1.) This would > create frustration with users who didn't realise they needed to flush > their cache (See 1 ...) > > Finally, I don't think it should be the default in the server product of > fedora. We often have a bind server on networks for servers which is > caching already. I agree on all points above except this one. Servers ESPECIALLY need to have a local DNS cache so they can continue working correctly when the primary nameserver goes down. In fact, the server case is even simpler--it can simply forward all requests to the first corporate/datacenter nameserver until it fails, and then fail over to the 2nd or 3rd DNS server in that case. It may not even have to support full DNSSEC validation because you may trust the datacenter's nameserver to do that for you. It certainly wouldn't have to deal with all the corner cases that clients have to deal with that you mention above such as flushing the cache on network link or route changes, VPN connection/disconnection, captive portals, etc. In fact, this is such an important use case that I'm tempted to create a separate Fedora Change for the Server Product with just this very basic limited functionality because we can do this very simply today without getting bogged down in the quagmire of DNSSEC, NTP bootstrapping, and all the client issues above. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 01:22:32PM +0800, P J P wrote: > > On Saturday, 12 April 2014 7:38 AM, Simo Sorce wrote: > > Not true, in many networks you want it, for example in corporate > > networks. You really want to be able to resolve the local resources and > > they are only resolvable if you consult the local DNS as provided to you > > by DHCP. > > True. The local resolver can be configured to resolve internal domains by > pointing it to the dynamic name servers. Also one can set 'DNS1=127.0.0.1' in > /etc/sysconfig script, that way dynamic name servers are listed as DNS2, DNS3 > etc. > > For this very reason the dynamic name server entries need to go as > "..transitory name servers to be used by the trusted local resolver". You cannot rely on DNS2 and DNS3 to be queried UNLESS DNS1=127.0.0.1 fails to respond. This might be a way to mitigate failure of the local caching resolver process, but it is not a way to ensure the ability to resolve internal names from the corporate nameserver. The way to ensure the latter is to configure the local caching resolver to forward to the DHCP-provided nameservers rather than becoming a full iterative resolver. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 02:09:19PM +0800, P J P wrote: > > On Saturday, 12 April 2014 11:11 AM, William Brown wrote: > > Say I have freshly installed my fedora system at home. I then boot it up > > and start to use it. My laptop is caching DNS results all the while from > > the "unreliable" ISP. > > > > I then go to work and suddenly things don't work. > > > > Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a > > complaint with your ISP. > > What, no! that was the case for having local cache and not forwarding > queries to the ISP's name servers at all. Because those are not reliable. I disagree. You can still do DNSSEC validation with a local caching resolver and configure that local resolver to forward all queries to the ISP. That should be tried first, and only bypassed and become a full interative recursive querier bypassing the ISP resolvers if that fails. We need to respect the DNS caching infrastructure by default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, Apr 11, 2014 at 10:44:31PM -0400, Paul Wouters wrote: > On Fri, 11 Apr 2014, Simo Sorce wrote: > > >>I hope the NM integration will show up at some point. It's really a > >>pretty nice setup. > > > >I am using it too successfully. Only occasionally unbound seem to get > >confused, not clear when, it doesn't happen more than twice a month and > >systemctl restart unbound.service fixes it. > > Next time please run sudo unbound-control list_forwards and cat > /etc/resolv.conf and see if that locates the problem? > > The one issue I have is that sometimes I NM fails to write resolv.conf > in insecure mode, and I end up with no resolvers. The other issue is that > in insecure mode (which you are not meant to run in other than signon or > with very broken captive portals)) the VPN forward is added to unbound, > but unbound is bypassed during secure mode, so internal resources are > not available. I'm proposing that /etc/resolv.conf is never re-written under any circumstances. A local caching resolver should ALWAYS be used and resolv.conf should ALWAYS say: nameserver 127.0.0.1 so that the applications/services don't hang when ONE external server goes down or becomes unreachable. All the "magic" for secure/insecure modes during NTP bootstrapping or captive portals has to happen inside unbound (or whatever caching resolver/forwarder is eventually chosen) and it should never be bypassed. That way the forwarder can switch to a second, third, etc. upstream resolver without applications noticing that the first one failed. Or if it is a full iterative resolver, it will internally handle failed authoritative nameservers without applications noticing. Maybe we should set the file to be immutable after setting it to 127.0.0.1: chattr +i /etc/resolv.conf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> On Saturday, 12 April 2014 4:55 PM, William Brown wrote: > This isn't how DNS works . You populate your cache from the ISP, who > queries above them and so on up to the root server. > http://technet.microsoft.com/en-us/library/cc961401.aspx Hmmn. There are two ways a local resolver can be configured. One is it contacts root servers and builds its cache from their responses. That's recursive name resolution. And second is it acts like a stub resolver and forwards client queries to another recursive resolver. N-DJBDNS supports both these options. Maybe you could install it and see for yourself. try -> # yum install ndjbdns > I should clarify. I cache the record foo.work.com from the office, and > it resolves differently externally. When I go home, it no longer > resolves to the external IP as I'm using the internally acquired record > from cache. No. Your foo.work.com address does not resolve to a public internet address, but resolves to an internal company specific address. And when you come home, your domain foo.work.com still resolves to the _same_ internal address, but you are unable to connect to it because you are outside of the office network. Try connecting over VPN connection from home. > A local cache will help you with 1 "sometimes" provided you get the > first record back once. > > It won't prevent the second or third as you will just cache the > incorrect data instead (Provided you clear cache on network change, this > isn't a problem ... it just means you hold onto bad data for that > session for longer, which creates other issues.) > > I personally am actually against DNS cache on systems as it tends to > create more problems than it solves. Maybe you could try N-DJBDNS -> # yum install ndjbdns --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
Am 12.04.2014 13:25, schrieb William Brown: >>> Consider, I get home, and open my laptop. Cache is cleared, >>> and I'm now populating that cache with the contents from the ISP. >> >> No, why contents from ISP? Local resolver will populate cache from root >> servers, no? > > This isn't how DNS works . You populate your cache from the ISP, who > queries above them and so on up to the root server. no - only if you enter your ISP's servers as forwarder which makes only partial sense because it lowers the effective TTL and you have more and more cahcings between the origin and your machine while some of them may ignore TTL at all a DNS server doing recursion don't ask any forwarder > http://technet.microsoft.com/en-us/library/cc961401.aspx nice, but you need to understand the contents especially point 3 and because point 1-8 it is called "recursion" because you sart to ask the root-servers which tell you "hey i don't konw the address, but i know who knows .com" followed by the server for .com answers "well, i don't know the answer but i can tell you who knows" signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> > > Consider, I get home, and open my laptop. Cache is cleared, > > and I'm now populating that cache with the contents from the ISP. > > No, why contents from ISP? Local resolver will populate cache from root > servers, no? This isn't how DNS works . You populate your cache from the ISP, who queries above them and so on up to the root server. http://technet.microsoft.com/en-us/library/cc961401.aspx > > > But if you weren't to clear the cache, I could be at home caching bad > > records, > > then when I go to work they persist. > > This is a glitch that when you are at home the cache still has office > domain addresses cached, to which you can not connect, because you aren't > connected to the office network. Do I understand it right? IMO, that's not > bad cache. > I should clarify. I cache the record foo.work.com from the office, and it resolves differently externally. When I go home, it no longer resolves to the external IP as I'm using the internally acquired record from cache. > > You cannot have both. I would rather that cache is flushed on interface > > change > > as it prevents so many more issues than making that cache last across > > potential > > network boundaries. > > Sure, no contention there. IMO, that could be a feature for NM, to clear > local cache on interface change. Because NM is suitably placed to do that. > Agreed. > > At the end of the day, I cannot stress enough, if you have an ISP with bad > > DNS > > caching or that is unreliable, you need to fault your ISP, > > IMO, local resolver can help here. > > --- > > On Sat, 2014-04-12 at 16:15 +0800, P J P wrote: > > > On Saturday, 12 April 2014 12:41 PM, William Brown wrote: > > > PS: The unreliable ISP I perceive as: > > > 1) They often return no query within an acceptable time period > > > 2) They return invalid or incorrect zone data > > > 3) They mess with TTLs or other zone data > > > > Right. Referencing these together. A local cache will help you with 1 "sometimes" provided you get the first record back once. It won't prevent the second or third as you will just cache the incorrect data instead (Provided you clear cache on network change, this isn't a problem ... it just means you hold onto bad data for that session for longer, which creates other issues.) I personally am actually against DNS cache on systems as it tends to create more problems than it solves. -- William Brown signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> On Saturday, 12 April 2014 12:41 PM, William Brown wrote: > PS: The unreliable ISP I perceive as: > 1) They often return no query within an acceptable time period > 2) They return invalid or incorrect zone data > 3) They mess with TTLs or other zone data Right. > Consider, I get home, and open my laptop. Cache is cleared, > and I'm now populating that cache with the contents from the ISP. No, why contents from ISP? Local resolver will populate cache from root servers, no? > But if you weren't to clear the cache, I could be at home caching bad records, > then when I go to work they persist. This is a glitch that when you are at home the cache still has office domain addresses cached, to which you can not connect, because you aren't connected to the office network. Do I understand it right? IMO, that's not bad cache. > You cannot have both. I would rather that cache is flushed on interface change > as it prevents so many more issues than making that cache last across > potential > network boundaries. Sure, no contention there. IMO, that could be a feature for NM, to clear local cache on interface change. Because NM is suitably placed to do that. > At the end of the day, I cannot stress enough, if you have an ISP with bad DNS > caching or that is unreliable, you need to fault your ISP, IMO, local resolver can help here. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 2014-04-12 at 14:09 +0800, P J P wrote: > > On Saturday, 12 April 2014 11:11 AM, William Brown wrote: > > Say I have freshly installed my fedora system at home. I then boot it up > > and start to use it. My laptop is caching DNS results all the while from > > the "unreliable" ISP. > > PS: The unreliable ISP I perceive as: 1) They often return no query within an acceptable time period 2) They return invalid or incorrect zone data 3) They mess with TTLs or other zone data -- William Brown signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 2014-04-12 at 14:09 +0800, P J P wrote: > > On Saturday, 12 April 2014 11:11 AM, William Brown wrote: > > Say I have freshly installed my fedora system at home. I then boot it up > > and start to use it. My laptop is caching DNS results all the while from > > the "unreliable" ISP. > > > > I then go to work and suddenly things don't work. > > > > Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a > > complaint with your ISP. > > What, no! that was the case for having local cache and not forwarding > queries to the ISP's name servers at all. Because those are not reliable. > > > See my previous email, about flushing the cache on network change. > > Yes I saw. About automatic cache clearance etc. I agree. Those are features > to be requested from the DNS software or maybe NM. I've been using 'dnscache' > without any trouble whatsoever. > Umm what? You cannot have your cake and eat it too. If you flush the cache of interface route change, the entire point you made about trying to no forward to an unreliable ISP is invalid. Consider, I get home, and open my laptop. Cache is cleared, and I'm now populating that cache with the contents from the ISP. But if you weren't to clear the cache, I could be at home caching bad records, then when I go to work they persist. You cannot have both. I would rather that cache is flushed on interface change as it prevents so many more issues than making that cache last across potential network boundaries. At the end of the day, I cannot stress enough, if you have an ISP with bad DNS caching or that is unreliable, you need to fault your ISP, it is not an issue for the OS to solve. -- William Brown signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> On Saturday, 12 April 2014 11:11 AM, William Brown wrote: > Say I have freshly installed my fedora system at home. I then boot it up > and start to use it. My laptop is caching DNS results all the while from > the "unreliable" ISP. > > I then go to work and suddenly things don't work. > > Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a > complaint with your ISP. What, no! that was the case for having local cache and not forwarding queries to the ISP's name servers at all. Because those are not reliable. > See my previous email, about flushing the cache on network change. Yes I saw. About automatic cache clearance etc. I agree. Those are features to be requested from the DNS software or maybe NM. I've been using 'dnscache' without any trouble whatsoever. See -> http://pjp.dgplug.org/ndjbdns/ --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 15:11:35 +0930, William Brown wrote: That makes no sense. Say I have freshly installed my fedora system at home. I then boot it up and start to use it. My laptop is caching DNS results all the while from the "unreliable" ISP. I then go to work and suddenly things don't work. Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a complaint with your ISP. No, but using a caching iterative resolver does. (Barring the ISP rewriting your traffic.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 2014-04-12 at 13:35 +0800, P J P wrote: > > On Saturday, 12 April 2014 10:33 AM, P J P wrote: > > >> On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote:> > >> It's rude to bypass the global DNS caching infrastructure. That would > >> significantly load people's DNS servers with more queries. There is no > >> reason not to try and use ISP's DNS caches. > > There is also the case that Chuck mentioned about ISP's name servers being > unreliable. > > --- > Regards >-Prasad > http://feedmug.com That makes no sense. Say I have freshly installed my fedora system at home. I then boot it up and start to use it. My laptop is caching DNS results all the while from the "unreliable" ISP. I then go to work and suddenly things don't work. Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a complaint with your ISP. See my previous email, about flushing the cache on network change. -- William Brown signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> On Saturday, 12 April 2014 10:33 AM, P J P wrote: > >> On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote:> >> It's rude to bypass the global DNS caching infrastructure. That would >> significantly load people's DNS servers with more queries. There is no >> reason not to try and use ISP's DNS caches. There is also the case that Chuck mentioned about ISP's name servers being unreliable. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> On Saturday, 12 April 2014 7:38 AM, Simo Sorce wrote: > Not true, in many networks you want it, for example in corporate > networks. You really want to be able to resolve the local resources and > they are only resolvable if you consult the local DNS as provided to you > by DHCP. True. The local resolver can be configured to resolve internal domains by pointing it to the dynamic name servers. Also one can set 'DNS1=127.0.0.1' in /etc/sysconfig script, that way dynamic name servers are listed as DNS2, DNS3 etc. For this very reason the dynamic name server entries need to go as "..transitory name servers to be used by the trusted local resolver". --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> On Saturday, 12 April 2014 3:55 AM, Chuck Anderson wrote: > I think there needs to be more emphasis on the /other/ benefit, the > whole reason I brought this up this time: Sure; I tried to cover it in the detailed description as === ...Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. (See: [1], [2], [3]) === Also, this thread is linked there at [3]. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
Hello Kevin, Paul > On Saturday, 12 April 2014 2:16 AM, Kevin Fenzi wrote: >> I've been running this solution on fedora for about five years now. It >> works reasonably well, and anyone who is on this list surely has could >> try it out. Because of lack of NM integration I would not call it >> enduser ready yet. > > Me too. :) Does it work out of the box? I mean just $ yum install unbound and it works, or there are some steps involved to configure it neatly. For ex. internal domains etc. If so, it'll be extremely helpful to document these steps on the change wiki. Or if there is already a document about it, please link to the same. Or let me know and I'll do it. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
> On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote:> > It's rude to bypass the global DNS caching infrastructure. That would > significantly load people's DNS servers with more queries. There is no > reason not to try and use ISP's DNS caches. You mean let local resolver forward queries to the ISP's name servers? That is same as using ISP's name servers in '/etc/resolv.conf'. I wouldn't prefer that without DNSSEC. > dnscache is very obsolete software. -> http://pjp.dgplug.org/ndjbdns/ There is new version of it. It does not support DNSSEC, but is alive and well maintained. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, 2014-04-12 at 02:33 +0800, P J P wrote: > Hello, > > > On Thursday, 10 April 2014 11:39 PM, P J P wrote: > > I plan to file a feature/change request for this one. I got caught up with > > other > > work this past week so could not do it. Will start with it right away. > > Please see -> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > It's a System Wide Change Proposal request up for review. > > I have set the target release as F22, because the proposal deadline for F21 > was 08 Apr 2014 [1]. Besides, this change would require significant work on > the related packages like NetworkManager etc. So F22 seems safer. > > In case if you spot any discrepancies or have additional inputs or links to > relevant documents etc. please feel free to update the wiki page or let me > know and I'll add it there. > -- > [1] https://fedoraproject.org/wiki/Releases/21/Schedule I agree with the goal to add DNSSEC (Despite it's flaws). However, a caching DNS server can create many headaches without a number of considerations. First, it should be easily possible to clear / invalidate the cache for a GUI and CLI user. This isn't possible on windows for example, and is why often they ask people to reboot computers in the first instance of an issue or migration. Additionally, every time the interface state changes from up/down, or the default route changes, the cache should be cleared. Consider a user of a corporate network that serves both an internal zone and an external zone. The user may enter or exit the network, and cached records would continue to be served causing issue. Second, it can create issues as otherwise mentioned by "dodgy" hotspots. They server a fake DNS record for all hosts that resolves to the hostspot. When the client authenticates they begin to serve the real records. If these records are cached, suddenly, the hotspot is now unusable (Especially if they don't set a TTL of say 1.) This would create frustration with users who didn't realise they needed to flush their cache (See 1 ...) Finally, I don't think it should be the default in the server product of fedora. We often have a bind server on networks for servers which is caching already. Sincerely, -- William Brown signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, 11 Apr 2014, Simo Sorce wrote: I hope the NM integration will show up at some point. It's really a pretty nice setup. I am using it too successfully. Only occasionally unbound seem to get confused, not clear when, it doesn't happen more than twice a month and systemctl restart unbound.service fixes it. Next time please run sudo unbound-control list_forwards and cat /etc/resolv.conf and see if that locates the problem? The one issue I have is that sometimes I NM fails to write resolv.conf in insecure mode, and I end up with no resolvers. The other issue is that in insecure mode (which you are not meant to run in other than signon or with very broken captive portals)) the VPN forward is added to unbound, but unbound is bypassed during secure mode, so internal resources are not available. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, 2014-04-11 at 14:45 -0600, Kevin Fenzi wrote: > On Fri, 11 Apr 2014 16:39:34 -0400 (EDT) > Paul Wouters wrote: > > ...snip... > > > I've been running this solution on fedora for about five years now. It > > works reasonably well, and anyone who is on this list surely has could > > try it out. Because of lack of NM integration I would not call it > > enduser ready yet. > > Me too. :) > > I hope the NM integration will show up at some point. It's really a > pretty nice setup. I am using it too successfully. Only occasionally unbound seem to get confused, not clear when, it doesn't happen more than twice a month and systemctl restart unbound.service fixes it. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, 2014-04-11 at 15:22 -0500, Bruno Wolff III wrote: > On Fri, Apr 11, 2014 at 14:21:30 -0500, >Dan Williams wrote: > > > >NM in F20+ already has a "dns=none" option that prevents NM from > >touching resolv.conf, but obviously if NM isn't touching it, the DNS > >information that NM gets from upstream or your local configuration needs > >to get to the local caching nameserver somehow. Which is what the > >existing NM DNS plugins are for, like the dnsmasq one. > > If you are running a caching resolver you don't need the DNS information > from DCHP (except except for the hotspot issue) at all. For example, > dnscache can be used for this. (It doesn't do dnssec though, so wouldn't > provide what is wanted for the proposal.) Not true, in many networks you want it, for example in corporate networks. You really want to be able to resolve the local resources and they are only resolvable if you consult the local DNS as provided to you by DHCP. For hotspots in public places that doesn't matter as much of course. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, 11 Apr 2014, Bruno Wolff III wrote: Second, I still don't understand the point. Are you suggesting it is better to believe all DNS lies than to not know where the lies lead? Not better. That DNSSEC doesn't really solve everythin one might want it to. And hence one might want to avoid ISPs' DNS services in some cases. Which is why we do captive portal detection, but would like to see better NM integration for it. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, Apr 11, 2014 at 18:44:21 -0400, Paul Wouters wrote: First, TTLs you receive from a forwarder can always be manipulated, even with DNSSEC - otherwise caching wouldn't work. Second, I still don't understand the point. Are you suggesting it is better to believe all DNS lies than to not know where the lies lead? Not better. That DNSSEC doesn't really solve everythin one might want it to. And hence one might want to avoid ISPs' DNS services in some cases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, 11 Apr 2014, Bruno Wolff III wrote: I'm not sure what you are trying to say here. It was a comment about ISPs changing TTLs (or other things). DNSSEC can be used to tell you the data might not be authoritative, but doesn't tell you what the correct information is. First, TTLs you receive from a forwarder can always be manipulated, even with DNSSEC - otherwise caching wouldn't work. Second, I still don't understand the point. Are you suggesting it is better to believe all DNS lies than to not know where the lies lead? Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Sat, Apr 12, 2014 at 02:33:59AM +0800, P J P wrote: > Hello, > > > On Thursday, 10 April 2014 11:39 PM, P J P wrote: > > I plan to file a feature/change request for this one. I got caught up with > > other > > work this past week so could not do it. Will start with it right away. > > Please see -> > https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver > > It's a System Wide Change Proposal request up for review. > > I have set the target release as F22, because the proposal deadline for F21 > was 08 Apr 2014 [1]. Besides, this change would require significant work on > the related packages like NetworkManager etc. So F22 seems safer. > > In case if you spot any discrepancies or have additional inputs or links to > relevant documents etc. please feel free to update the wiki page or let me > know and I'll add it there. > -- > [1] https://fedoraproject.org/wiki/Releases/21/Schedule Thank you! I think there needs to be more emphasis on the /other/ benefit, the whole reason I brought this up this time: While DNSSEC support has historically been a driving factor for implementing this, there is an even more fundamental need due to the poor performance of the system in case the first listed nameserver in /etc/resolv.conf fails for some reason. It is shameful that Linux systems and applications in general still, after 20+ years, can't perform adequately after a primary DNS server failure. The stub resolver in glibc which uses /etc/resolv.conf can decide that the first listed nameserver entry is down, but this decision has to be made over and over in every single process on the system that is doing DNS resolution, resulting in repeated long application hangs/delays. We need an independent, system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to solve this fundamental design problem with how name resolution works on a Linux system. Windows has had a default system-wide DNS cache for over a decade. It is about time that Linux catches up. I can have a go at adding some text to the wiki. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, 2014-04-11 at 14:45 -0600, Kevin Fenzi wrote: > On Fri, 11 Apr 2014 16:39:34 -0400 (EDT) > Paul Wouters wrote: > > ...snip... > > > I've been running this solution on fedora for about five years now. It > > works reasonably well, and anyone who is on this list surely has could > > try it out. Because of lack of NM integration I would not call it > > enduser ready yet. > > Me too. :) > > I hope the NM integration will show up at some point. It's really a > pretty nice setup. It's getting worked on, slowly but surely. And since DNSSEC has been getting more interest, we've been having a lot more discussions about how NetworkManager can better serve dnssec-trigger and other DNS consumers like it. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, Apr 11, 2014 at 17:46:29 -0400, Paul Wouters wrote: I'm not sure what you are trying to say here. It was a comment about ISPs changing TTLs (or other things). DNSSEC can be used to tell you the data might not be authoritative, but doesn't tell you what the correct information is. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, 11 Apr 2014, Bruno Wolff III wrote: If you don't know there is an exception for a domain (eg at the other end of a VPN) than you will get the public answers and might not get where you need to go. Additionally, with DNSSEC there is the problem that the public view cryptographically proves the internal view does not exist (eg internal.fedoraproject.org) With an iterative resolver that may not be true. If the route to the name server that has that information is over the VPN (so that you have the correct source address), you should get the right answer. Sounds like putting RFC1918 addresses in public DNS? Eww. Also, unbound strips those out unless they come in via forwarders. But also selecting DNS servers does not relate to routing at all, so this is confusing to me. Indeed, with DNSSEC we can use them as cache, because we can validate the answers. But those servers should never be "trusted". That doesn't get you the right answers though, it only tells you that they are lying. I'm not sure what you are trying to say here. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS caching name server
On Fri, 11 Apr 2014, Chris Adams wrote: Once upon a time, Bruno Wolff III said: The advantage of using your dns server is that you know what you're getting. You'll also lose almost all content-delivery network advantages (most of that is mapped to "close" servers with DNS). Another reason to attempt to configure your locally running DNSSEC resolver with your ISP's DNS servers as forwarder Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
