> ?I don't even see DNSSEC helping much here, either, given that the attacker could just strip out the DNSSEC > info (unless, perhaps, the home computers were running full (vs stub) recursive resolvers that also did DNSSEC-validation).
Recursive resolvers, if run responsibly can help alleviate some of the problems. For example, one can use IP address-based authorization and the inbound interface (where queries arrive) to limit recursion to authorized clients (BCP 140 <http://www.ietf.org/rfc/rfc5358.txt>), apply response rate limiting (DNS RRL <http://ss.vix.su/~vixie/isc-tn-2012-1.txt>), and use traffic filters to prevent source IP spoofing (BCP 38)<http://tools.ietf.org/html/bcp38> on your networks. For mobile clients, BCP 140 recommends that you have clients connect to your network using a VPN, where they can use your recursive resolver. BCP 140 also suggests that you might run a local caching recursive resolver on mobile devices. N On 7 March 2014 22:11, <[email protected]> wrote: > Send DNSOP mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/dnsop > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of DNSOP digest..." > > > Today's Topics: > > 1. Re: DNS privacy and Team Cymru's report on 300, 000 SOHO > routers with compromised DNS settings (Paul Wouters) > 2. Re: DNS privacy and Team Cymru's report on 300, 000 SOHO > routers with compromised DNS settings (Tony Finch) > 3. Updating Parent Zones proposal - feedback from registries > and registrars (Francisco Arias) > 4. CPE devices doing DNSSEC (Mark Andrews) > 5. Re: CPE devices doing DNSSEC (Joe Abley) > 6. Re: pushing updates to the parent (Tony Finch) > 7. Passive DNS COF (Lawrence Conroy) > 8. Re: pushing updates to the parent (Joe Abley) > 9. I-D Action: > draft-ietf-dnsop-dnssec-roadblock-avoidance-00.txt > ([email protected]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 7 Mar 2014 04:00:34 -0500 (EST) > From: Paul Wouters <[email protected]> > To: Dan York <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 > SOHO routers with compromised DNS settings > Message-ID: <[email protected]> > Content-Type: TEXT/PLAIN; format=flowed; charset=ISO-8859-15 > > On Thu, 6 Mar 2014, Dan York wrote: > > > Now, in this case the attackers compromised the local network devices > and took over control of the local recursive resolvers. ?In this > > case of the attacker controlling the recursive resolver, I don't know > that any of the various solutions thrown around today would do > > anything to help with this. > > Run a local resolver and reconfigure it automatically (eg using > dnssec-trigger and friends) to use the DHCP obtained DNS servers > only as forwarders. > > > ?I don't even see DNSSEC helping much here, either, given that the > attacker could just strip out the DNSSEC > > info (unless, perhaps, the home computers were running full (vs stub) > recursive resolvers that also did DNSSEC-validation). > > If the domains were signed, even if you used the rogue DNS as forwarder, > you would at least notice you are under attack. > > Paul > > > > ------------------------------ > > Message: 2 > Date: Fri, 7 Mar 2014 09:20:51 +0000 > From: Tony Finch <[email protected]> > To: Paul Wouters <[email protected]> > Cc: "[email protected]" <[email protected]>, Dan York <[email protected]> > Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 > SOHO routers with compromised DNS settings > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Paul Wouters <[email protected]> wrote: > > On Thu, 6 Mar 2014, Dan York wrote: > > > > >?I don't even see DNSSEC helping much here, either, given that the > > > attacker could just strip out the DNSSEC info (unless, perhaps, the > > > home computers were running full (vs stub) recursive resolvers that > > > also did DNSSEC-validation). > > > > If the domains were signed, even if you used the rogue DNS as forwarder, > > you would at least notice you are under attack. > > As I understand it from the CERT Polska report, the aim of the malware is > to send people to a phishing site instead of to legit banking sites etc. > > http://www.cert.pl/news/8019/langswitch_lang/en > (if you get a redirect try reloading the link) > > If properly deployed, with validation on the users' end hosts, DNSSEC > would absolutely have prevented this attack from successfully stealing > banking credentials. > > Tony. > -- > f.anthony.n.finch <[email protected]> http://dotat.at/ > Northwest FitzRoy, Sole: Northerly, backing southerly later, 4 or 5, > increasing 6 or 7, perhaps gale 8 later. Rough or very rough. Rain or > drizzle. > Moderate occasionally poor. > > ------------------------------ > > Message: 3 > Date: Fri, 7 Mar 2014 01:47:50 -0800 > From: Francisco Arias <[email protected]> > To: Tim Wicinski <[email protected]>, Mark Andrews <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: [DNSOP] Updating Parent Zones proposal - feedback from > registries and registrars > Message-ID: <cf3f4533.53d45%[email protected]> > Content-Type: text/plain; charset="utf-8" > > A option to obtain feedback from gTLD registries and registrars would be > to use the [email protected] mailing list: > https://mm.icann.org/mailman/listinfo/gtld-tech > > Regards, > > -- > Francisco. > > > > > ------------------------------ > > Message: 4 > Date: Fri, 07 Mar 2014 21:05:24 +1100 > From: Mark Andrews <[email protected]> > To: [email protected] > Subject: [DNSOP] CPE devices doing DNSSEC > Message-ID: <[email protected]> > > > What do we expect CPE devices to implement to update parent > zones. 100 different things to cover all the update methods > registrar's come up with. Or do we say do exactly one > method that works in all situations? > > We already have a problem today were they can't do dynamic > update to every dynamic dns provider because they implement > non standard adhoc methods rather that one standardised > method. > > I know Registrars don't like to be told what to do but this > is a case where interop from 100's of CPE providers and > 1000000's of parent zones made up of RRR zones and non RRR zones > needs to work reliably without lots of choice. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > > > ------------------------------ > > Message: 5 > Date: Fri, 7 Mar 2014 10:21:34 +0000 > From: Joe Abley <[email protected]> > To: Mark Andrews <[email protected]> > Cc: [email protected] > Subject: Re: [DNSOP] CPE devices doing DNSSEC > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > On 7 Mar 2014, at 10:05, Mark Andrews <[email protected]> wrote: > > > What do we expect CPE devices to implement to update parent > > zones. 100 different things to cover all the update methods > > registrar's come up with. Or do we say do exactly one > > method that works in all situations? > > > > We already have a problem today were they can't do dynamic > > update to every dynamic dns provider because they implement > > non standard adhoc methods rather that one standardised > > method. > > https://xkcd.com/927/ > > > Joe > > > > ------------------------------ > > Message: 6 > Date: Fri, 7 Mar 2014 10:49:50 +0000 > From: Tony Finch <[email protected]> > To: Joe Abley <[email protected]> > Cc: [email protected] > Subject: Re: [DNSOP] pushing updates to the parent > Message-ID: > <[email protected]> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Joe Abley <[email protected]> wrote: > > > > https://xkcd.com/927/ > > So from the standards development point of view, I think what this is > saying is that success is more likely to come from building on what people > are already doing and nudging more of them to do it more similarly. > > The problem with the parent update process is that there's a hopeless zoo > of more-or-less crappy APIs almost none of which are good foundations. > > For a push-style protocol there are two parts: finding out where to push > the update; and how to push the update. > > The where question ought to be answered by whois or weirds or _update SRV > records. > > The how question ought to be answered by EPP (from registrant to > registrar) or DNS UPDATE. It would be nice if there were software to > gateway between one and the other. > > Tony. > -- > f.anthony.n.finch <[email protected]> http://dotat.at/ > Humber: Southwest 6 to gale 8, becoming variable 4, then southeast 5 later. > Slight or moderate. Rain, becoming fair. Moderate becoming good. > > > > ------------------------------ > > Message: 7 > Date: Fri, 7 Mar 2014 11:23:05 +0000 > From: Lawrence Conroy <[email protected]> > To: [email protected] > Subject: [DNSOP] Passive DNS COF > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > Hi Chaps, > stupid quick question, listening to the stream: > How does this work with CDNs (I think you may need to capture the IP > address; bailiwick could act as a proxy for that, but ...) > all the best, > Lawrence > > > > ------------------------------ > > Message: 8 > Date: Fri, 7 Mar 2014 15:39:37 +0000 > From: Joe Abley <[email protected]> > To: Tony Finch <[email protected]> > Cc: [email protected] > Subject: Re: [DNSOP] pushing updates to the parent > Message-ID: <[email protected]> > Content-Type: text/plain; charset=us-ascii > > > On 7 Mar 2014, at 10:49, Tony Finch <[email protected]> wrote: > > > Joe Abley <[email protected]> wrote: > > > >> https://xkcd.com/927/ > > > > So from the standards development point of view, I think what this is > > saying is that success is more likely to come from building on what > people > > are already doing and nudging more of them to do it more similarly. > > Sure, maybe. > > I think we have to consider our target audience. Part of that is to > consider the existing menagerie and understanding the shape of the expected > solutions space. > > While we in this group might find comfort in arcane binary protocols using > UDP port 53, the habits of people who frequent the dyndns zoo seem to be > far more tilted towards throwing JSON documents around over HTTP. It's hard > to imagine unifying a pile of RESTish APIs with something that looks > foreign and different. > > I'll +1 Andrew and say that I have my doubts (a) that the underscore > scaffolding will ever appear in the top-most labels and (b) that anybody > would use them if they did. > > My poorly-informed doubt is hardly a reason not to document the idea. But > I think it's a stretch to expect anything more than an XKCD-927 result. > > > Joe > > > > ------------------------------ > > Message: 9 > Date: Fri, 07 Mar 2014 08:41:53 -0800 > From: [email protected] > To: [email protected] > Cc: [email protected] > Subject: [DNSOP] I-D Action: > draft-ietf-dnsop-dnssec-roadblock-avoidance-00.txt > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations Working > Group of the IETF. > > Title : DNSSEC Roadblock Avoidance > Authors : Wes Hardaker > Olafur Gudmundsson > Suresh Krishnaswamy > Filename : > draft-ietf-dnsop-dnssec-roadblock-avoidance-00.txt > Pages : 16 > Date : 2014-03-07 > > Abstract: > This document describes problems that a DNSSEC aware resolver/ > application might run into within a non-compliant infrastructure. It > outline potential detection and mitigation techniques. The scope of > the document is to create a shared approache to detect and overcome > network issues that a DNSSEC software/system may face. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > > > ------------------------------ > > End of DNSOP Digest, Vol 88, Issue 21 > ************************************* >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
