> ?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, <dnsop-requ...@ietf.org> wrote: > Send DNSOP mailing list submissions to > dnsop@ietf.org > > 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 > dnsop-requ...@ietf.org > > You can reach the person managing the list at > dnsop-ow...@ietf.org > > 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 > (internet-dra...@ietf.org) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 7 Mar 2014 04:00:34 -0500 (EST) > From: Paul Wouters <p...@cypherpunks.ca> > To: Dan York <y...@isoc.org> > Cc: "dnsop@ietf.org" <dnsop@ietf.org> > Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 > SOHO routers with compromised DNS settings > Message-ID: <alpine.lfd.2.10.1403070357140.10...@bofh.nohats.ca> > 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 <d...@dotat.at> > To: Paul Wouters <p...@cypherpunks.ca> > Cc: "dnsop@ietf.org" <dnsop@ietf.org>, Dan York <y...@isoc.org> > Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 > SOHO routers with compromised DNS settings > Message-ID: > <alpine.lsu.2.00.1403070910170.19...@hermes-1.csi.cam.ac.uk> > Content-Type: text/plain; charset="utf-8" > > Paul Wouters <p...@cypherpunks.ca> 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 <d...@dotat.at> 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 <francisco.ar...@icann.org> > To: Tim Wicinski <tjw.i...@gmail.com>, Mark Andrews <ma...@isc.org> > Cc: "dnsop@ietf.org" <dnsop@ietf.org> > Subject: [DNSOP] Updating Parent Zones proposal - feedback from > registries and registrars > Message-ID: <cf3f4533.53d45%francisco.ar...@icann.org> > Content-Type: text/plain; charset="utf-8" > > A option to obtain feedback from gTLD registries and registrars would be > to use the gtld-t...@icann.org 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 <ma...@isc.org> > To: dnsop@ietf.org > Subject: [DNSOP] CPE devices doing DNSSEC > Message-ID: <20140307100524.2f42810cd...@rock.dv.isc.org> > > > 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: ma...@isc.org > > > > ------------------------------ > > Message: 5 > Date: Fri, 7 Mar 2014 10:21:34 +0000 > From: Joe Abley <jab...@hopcount.ca> > To: Mark Andrews <ma...@isc.org> > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] CPE devices doing DNSSEC > Message-ID: <3e0dc692-7ba0-4672-bb10-82b854bb6...@hopcount.ca> > Content-Type: text/plain; charset=us-ascii > > > On 7 Mar 2014, at 10:05, Mark Andrews <ma...@isc.org> 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 <d...@dotat.at> > To: Joe Abley <jab...@hopcount.ca> > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] pushing updates to the parent > Message-ID: > <alpine.lsu.2.00.1403071025270.19...@hermes-1.csi.cam.ac.uk> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > Joe Abley <jab...@hopcount.ca> 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 <d...@dotat.at> 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 <lcon...@insensate.co.uk> > To: dnsop@ietf.org > Subject: [DNSOP] Passive DNS COF > Message-ID: <b40ac4ba-0c5d-417c-9fc8-71ebf310f...@insensate.co.uk> > 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 <jab...@hopcount.ca> > To: Tony Finch <d...@dotat.at> > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] pushing updates to the parent > Message-ID: <8c184518-2a56-42b6-bd63-3e50f8126...@hopcount.ca> > Content-Type: text/plain; charset=us-ascii > > > On 7 Mar 2014, at 10:49, Tony Finch <d...@dotat.at> wrote: > > > Joe Abley <jab...@hopcount.ca> 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: internet-dra...@ietf.org > To: i-d-annou...@ietf.org > Cc: dnsop@ietf.org > Subject: [DNSOP] I-D Action: > draft-ietf-dnsop-dnssec-roadblock-avoidance-00.txt > Message-ID: <20140307164153.15062.39035.idtrac...@ietfa.amsl.com> > 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > ------------------------------ > > End of DNSOP Digest, Vol 88, Issue 21 > ************************************* >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
