Re: Jessie release goal: DNSSEC as default recursive resolver
On 10/28/2013 10:29 PM, Adam Borowski wrote:
> On Mon, Oct 28, 2013 at 01:01:13PM +0100, Thijs Kinkhorst wrote:
>> On Sat, October 26, 2013 18:52, Ondřej Surý wrote:
>>> we can adopt dnssec-trigger
>>
>> I think it's indeed very important that a default install uses the DHCP
>> provided DNS-servers or locally configured resolvers, because in many
>> networks that's the only way to reliably resolve things. dnssec-trigger
>> may provide that
>
> It might be worse. Some ISPs use an equivalent of:
> iptables [...] --dport 53 -j REDIRECT (or DNAT)
> to answer all queries locally. Reasons vary: reigning in Androids
> hard-coded for 8.8.8.8, censorship, hijacking NSDOMAIN for ads, etc.
>
> My personal story: years ago, a local garden-variety ISP (~300 users) had a
> problem because of computer shop which, in machines sold or repaired there,
> set DNS settings to those of a national near-monopoly ISP (for some cargo
> cult reasons). Then, one day, that national ISP turned off recursion for
> outside IPs. "Teh internet broke". The local ISP's guys came to me, as
> blaming the computer shop would end up just in losing customers because
> "your internet doesn't work and you lie blaming others -- easily proven
> by connecting that computer elsewhere". I proposed and implemented the
> above redirect which neatly fixed the problem.
>
> It's obvious what will happen if that redirected to DNS server blocks
> DS/RRSIG/NSEC/... queries (like typical crap home routers do). And even
> worse, this scenario is indistinguishable from some actual attacks DNSSEC
> guards against.
Gosh... This makes me think about China Telecom adding their own
advertizing on sites you visit and that they don't control, by adding
some broken javascript using their "transparent" proxy server... (not
sure if they continue to do this crap). :(
So, as per the replies we've read, it seems that the only way to
implement DNSSEC would be to first check if it works, and if it doesn't,
fallback to the locally provided recursive DNS server. And that must be
considering the use case where we do a setup in an environment where
DNSSEC works, then the laptop is plugged in one of these broken
networks, and the local resolver doesn't anymore. Otherwise our users
would blame Debian on this (for the same reason that above, you wouldn't
blame the repair shop...).
So, all this leads to believe we'd need a simple way to be able to
switch between a local DNSSEC enabled recursive resolver and a
my-isp-is-broken-provided-DNS. This can't be transparent to the user,
otherwise, what's the point of having DNSSEC if we don't know if it's
activated or not?
So at the end, I'm thinking (out loud): the only way would be to have
the desktop to show if DNSSEC is activated or not. Something like a
$desktop-applet or something. Has anyone ever wrote such software?
Thomas
Reply to: