Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000 SOHO routers with compromised DNS settings

From: Niranjan U <[email-masked]>
Date: Sat, 8 Mar 2014 22:48:45 +0530

> ?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-masked]> wrote:

> Send DNSOP mailing list submissions to
>         [email-masked]
>
> 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-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> 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-masked])
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 7 Mar 2014 04:00:34 -0500 (EST)
> From: Paul Wouters <[email-masked]>
> To: Dan York <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000
>         SOHO routers with compromised DNS settings
> Message-ID: <[email-masked]>
> 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-masked]>
> To: Paul Wouters <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Dan York <[email-masked]>
> Subject: Re: [DNSOP] DNS privacy and Team Cymru's report on 300, 000
>         SOHO routers with compromised DNS settings
> Message-ID:
>         <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
> Paul Wouters <[email-masked]> 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-masked]>  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-masked]>
> To: Tim Wicinski <[email-masked]>, Mark Andrews <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: [DNSOP] Updating Parent Zones proposal - feedback from
>         registries and registrars
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="utf-8"
>
> A option to obtain feedback from gTLD registries and registrars would be
> to use the [email-masked] 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-masked]>
> To: [email-masked]
> Subject: [DNSOP] CPE devices doing DNSSEC
> Message-ID: <[email-masked]>
>
>
>         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-masked]
>
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 7 Mar 2014 10:21:34 +0000
> From: Joe Abley <[email-masked]>
> To: Mark Andrews <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [DNSOP] CPE devices doing DNSSEC
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 7 Mar 2014, at 10:05, Mark Andrews <[email-masked]> 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-masked]>
> To: Joe Abley <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [DNSOP] pushing updates to the parent
> Message-ID:
>         <[email-masked]>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Joe Abley <[email-masked]> 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-masked]>  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-masked]>
> To: [email-masked]
> Subject: [DNSOP] Passive DNS COF
> Message-ID: <[email-masked]>
> 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-masked]>
> To: Tony Finch <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [DNSOP] pushing updates to the parent
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On 7 Mar 2014, at 10:49, Tony Finch <[email-masked]> wrote:
>
> > Joe Abley <[email-masked]> 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-masked]
> To: [email-masked]
> Cc: [email-masked]
> Subject: [DNSOP] I-D Action:
>         draft-ietf-dnsop-dnssec-roadblock-avoidance-00.txt
> Message-ID: <[email-masked]>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> ------------------------------
>
> End of DNSOP Digest, Vol 88, Issue 21
> *************************************
>