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 outsource your DNSSEC
validation over an insecure transport (LAN). That seems like a very bad
idea.
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.
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.
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.
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.
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.
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.
Paul
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
