> > > 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 from happening. No no no!!!! You need to flush *all* entries. Consider what I resolve www.google.com to. That changes *per* ISP because google provides different DNS endpoints and zones to ISPs to optimise traffic! So when I use google at work, I'm now getting a suboptimal route to their servers! > > > 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. So that's a valid point: A non-caching unbound that caps TTLs is a good idea, but as you say, you can't stop a dodgy ISP. > > > 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. But this isn't even an odd use case. There are enough power users in the world who do this. It's not just computer enthusiasts, I know a chemist who did this, and others. You can't just assume a generic case, and then break it for others. > > > 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 outsource your DNSSEC > validation over an insecure transport (LAN). That seems like a very bad > idea. If your lan is insecure, you have other issues. That isn't the problem you are trying to solve. > > > They have bind / named setup, and they would like to rely on that > > instead. > > They can. DNS caches are chained. There is no reason to say you cannot > run your own cache and have a network based cache. But you don't *need* it. I went to efforts to setup my own bind to cache, I shouldn't need it on my system. Again, local caches cause all kinds of issues. A home user is likely to toy with things and set a high-ish ttl, say even 10 minutes, and change records on their server. Then their records appear broken, because the local cache isn't expired yet. > > > 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. > 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. It's not contrived: This is a common network setup for all the people I know who are enthusiasts or how they setup their home networks. This is why it's a use case. > > 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. The issue is that by adding DNSSEC in this way, you are going to cause a great deal of pain because these caches. Add DNSSEC, but if you need to cache, cache for the most minimal time possible. > > > > Case 4, 5, 6 and 7: DNS cache, again, isn't needed. > > Again, DNSSEC validation on the device requires caching. > > > 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. It's linked to the other cases. It's the point that local system caches aren't needed as you have access to highly reliable DNS systems. Additionally, business networks are "trusted" so you can trust their DNS caches etc. (to a point) > > > 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. > > The VPN cases aleady work very well in Fedora. I seamlessly connect and > disconnect from the redhat VPN. Resources that are available only via > the VPN are never blocked by wrong DNS cache I got from when the VPN was > down. VPNs are a non-issue. Consider a business with external and internal DNS zones. This becomes an issue in this case. If you have cached say "website.example.com" to the external IP, and that is DMZed somehow on the internal network, when you change to VPN, you need to use the internal view of that zone instead. But you can't the name is cached. > > > 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. > > > * 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. No, cache is not a feature. It's a chronic issue. Look at windows systems that service desks around the world always advise the first step is reboot: Why? Flush dns caches (Or other things). When you can't get to a website? Restart the webbrower, to flush the cache. Intermittent network issues for different people on a network? The cache is allowing some people to work, but masking the issue to them. It's not allowing people to quickly and effectively isolate issues. DNSSEC is a good idea: Caches are a problem. If this really is to be used, I cannot stress enough, that a cache must be completely flushed every time the default route or network interface changes. You can't, and I can't possibly conceive every network setup in the world. If you make assumptions like this, systems will break and fedora will be blamed. -- William Brown <william@xxxxxxxxxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
