On Thu, May 30, 2013 at 05:51:28PM +0100, Ben Laurie wrote:
> > So is your concern that at this time DNSSEC lookup are too likely to
> > return "bogus" (rather than with anything specific in DANE itself)?
>
> Indeed.
Understood. There are perhaps work-arounds, and this should improve
over time.
> >> The issue is not that the clients can't use DNSSEC, the issue is that
> >> they cannot retrieve DNSSEC records.
> >
> > Well, there's always 8.8.8.8:
>
> How does that help if you can't retrieve DNSSEC records?
The Google 8.8.8.8 DNS cache does return DNSSEC records, as shown
below: So clients that can reach 8.8.8.8 or similar, can bypass
their ISP's cache when the ISP cache is DNSSEC hostile.
The remaining issue is jailed clients joining hotspots, ... that
may not be able to reach any external DNS servers. This too can
be addressed (for example via the "CD" bit and HTTP and perhaps
a UI for joining networks that disables DNSSEC until the mobile
device is out of jail).
Longer term joining public networks should be handled at the
802.1X layer with suitable mobile devices UIs. Not via MITM
on DNS and browsers.
> > $ drill -D -t ns com. @8.8.8.8
> > ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 25827
> > ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: > > 0
> > ;; QUESTION SECTION:
> > ;; com. IN NS
> >
> > ;; ANSWER SECTION:
> > com. 21033 IN NS a.gtld-servers.net.
> > ...
> > com. 21033 IN NS m.gtld-servers.net.
> > com. 21033 IN RRSIG NS 8 1 172800 20130603042012
> > 20130527031012 35519 com.
> > nETo/p1pX2mJo+BHZI20iQkgIGVTgbnqZ8vNf+CDy3w4/LJwrtP/r0NLBVzaQ/xpSLrxnkoxY9aRGtuwJp7oTOdTcq9gCN/QYyPuLK4gZT6BwjnOZmlVvyIQK8GKpafpsLniYX2xVGg07f7lpYdmRpMMZS4t5HXo46WZABXyYYU=
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
