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
[Test-Announce] 2014-04-14 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2014-04-14 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again on Monday! Let's check in. == Proposed Agenda Topics == 1. Previous meeting follow-up * adamw to put out the initial rawhide validation testing matrices and announcement mails 2. Rawhide validation testing * How's it working out so far? 3. Heartbleed status * Updates issued, respun images may need confirmation testing 4. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- 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: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: trimming down Fedora installed size
On 11/04/14 21:54, Richard W.M. Jones wrote: On Thu, Apr 10, 2014 at 06:13:42PM +0100, Andrew Price wrote: On 10/04/14 17:05, Bill Nottingham wrote: James Antill (ja...@fedoraproject.org) said: Not that I assume splitting lanauges and docs. into sub packages would triple primary numbers, but if it did ... that would be bad. To put it in perspective, if we split out 'langpacks' for apps per language, something like gedit then grows *100* new subpackages. Bill It's a shame we can't store .mo files compressed. Unfortunately .mo files are mmapped and shared between processes, so compressing them wouldn't work :-( That's what I thought :/ Just thinking out loud, but maybe with an updated gettext(3) it could work, but I guess it would require some hefty changes in libc, right? Unless programs could be linked against a "zintl" lib to provide an alternative gettext(3) perhaps. Either way it would need to be transparently backward compatible with the current .mo format and obviously there'd be performance concerns for some programs so they'd need to stick with the current implementation. Portability shouldn't be an issue though as .po files can be compiled to whatever .mo format the distro/package uses. I think there's potential for innovation in that area anyway, but it would need some momentum behind it. 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: F21 System Wide Change: The securetty file is empty by default
On Thu, Apr 10, 2014 at 2:30 AM, Daniel P. Berrange wrote: > On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote: >> >> This sounds entirely backwards, and I'd instead vote for removing >> securetty from the PAM stacks we ship altogether. The concept is >> outdated. It was useful in a time where the primary way to access a >> server was via physically attached TTY devices. But that time is mostly >> over... >> >> Nowadays the device names exposed by the kernel tend to be dynamically >> assigned, they should not be assumed stable (with one exeption, classic >> UART 16650 serial ports). Stable paths for these devices we add in via >> symlinks these days, using /dev/*/by-path/, /dev/*/by-id/, -- as you >> might know from disk devices. Now, the securetty logic is unable to >> verify things using these symlinks, hence the entire concept is >> flawed. It will use an unsteable device name instead, making it mostly >> useless in hotplug scenarios. >> >> securetty is particularly annoying when we use containers. Tools like >> "machinectl login" will dynamically spawn a getty for you on a pts >> device in the container, but since pts is not listed in securetty you >> cannot log in as root by default. And you cannot event add a wildcard >> match of pts/* to it, to make this work nicely. > > Yep, the securetty file is one of only 2 remaining blockers for getting > login working out of the box in containers. Removing securetty would be a > great help there given the inability to wildcard pts/*. The other problem > is of course the horrible pam audit module, which the kernel guys are > hopefully working towards a solution for. > > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct --- On Wed, Apr 9, 2014 at 2:50 PM, Matthew Miller wrote: > On Wed, Apr 09, 2014 at 11:39:19PM +0200, Lennart Poettering wrote: >> To clarify this: while I believe dropping securetty from the default PAM >> config is the right thing to do, I am not vulunteering to do it. But I'd >> love to see somebody to pick this up! > > I looked, and I think this is just a change in util-linux package (not the > source even; the pam files are packaged as separate sources) + a note in the > release notes. It's not referenced in authconfig or anything. > > I guess maybe we'd also want to remove /etc/securetty to reduce confusion > (since the normal semantics are that missing file = nothing blocked), that's > in setup. > > But otherwise, I think it just comes down to filing an RFE and getting the > util-linux maintainer on board. Probably best after this change proposal > gets to FESCo -- at that point, I'll put this forward as a counter-proposal. > > -- > Matthew Miller-- Fedora Project-- > "Tepid change for the somewhat better!" > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Not that it matters much, but I support the counter-proposal based on 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 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: F21 system GCC changed to 4.9.0 prerelease
On Sat, Apr 12, 2014 at 11:41:48AM +0200, Zoltan Boszormenyi wrote:
> Any project I tried with
>./configure CFLAGS="-fsanitize=undefined -fsanitize=address"
> fails with:
>
> checking for gcc... gcc
> checking whether the C compiler works... no
>
> config.log reveals that libasan.so and libubsan.so are missing from the
> system.
> "yum install lib{a,ub}san.{i686,x86_64}" fixed it. Shouldn't gcc and gcc-c++
> packages require these libraries?
No, it's just those options that require the libraries. IMO, if we
multiply the number of saniter libraries (so far 3 and growing), by
the number of possible architectures supported by the same compiler, we
quickly get into a larger dependency tree then something you want to
install *always*.
Zbyszek
--
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: F21 system GCC changed to 4.9.0 prerelease
2014-04-10 19:38 keltezéssel, Orion Poplawski írta:
On 04/10/2014 04:23 AM, Jakub Jelinek wrote:
Hi!
FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
package no longer builds. To investigate runtime rather than compile time
issues, please consider using temporarily -fsanitize=undefined and/or
-fsanitize=address to look for undefined behavior in the packages
you own.
Jakub
I think I've found a regression in gfortran with list-directed reading
from character arrays: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60810
unless this is some kind of new standards compliance, but this seems to
have worked forever.
Any project I tried with
./configure CFLAGS="-fsanitize=undefined -fsanitize=address"
fails with:
checking for gcc... gcc
checking whether the C compiler works... no
config.log reveals that libasan.so and libubsan.so are missing from the system.
"yum install lib{a,ub}san.{i686,x86_64}" fixed it. Shouldn't gcc and gcc-c++
packages require these libraries?
Best regards,
Zoltán Böszörményi
--
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
