default local DNS caching name server

[Reindl Harald]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140412/3e19d212/attachment.sig>