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
would you pull me unbound as dependency?
But a requirement of automagically understanding what a local zone
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
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
> 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
> 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