Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Lanlan Pan <[e-mail]>]

Hi Warren,

Thanks for your work, :-)

I totally agree:  Not all Disposable Domains are wildcards like
xxx.github.io / xxx.blogspot.com / xxx.qzone.qq.com. So, wildcard solution
can not cover all example Disposable/Temporary Domains in the paper, as
your analysis.

The question is how to avoid unnecessary caches and queries, give recursive
more power to defense with wildcard issue.

As Ted's advice, for a better justification, I will do more analysis on
recursive cache, which kind of temporary domain is "particular", wildcard
domains or "domains has no incentive to publish a wildcard marker".


Warren Kumari <[e-mail]>于2017年8月22日周二 上午2:45写道：

> I was really trying to stay out of this thread...
>
>
> On Fri, Aug 18, 2017 at 1:05 PM, Ted Lemon <[e-mail]> wrote:
> > El 18 ag 2017, a les 11:33, Lanlan Pan <[e-mail]> va escriure:
> >
> > So, can you talk about how your proposal saves cost over using a
> heuristic?
> > It can be used with cache aging heuristic.
> > Heuristic read in aaa/bbb/ccc.foo.com, expire and move out;  then read
> in
> > xxx/yyy/zzz.foo.com,  expire and move out;  loop...
> > => Map aaa/bbb/ccc/xxx/yy/zzz.foo.com to *.foo.com when heuristic read,
> it
> > will reduce the load of move in/out.
> >
> >
> > By "move out" you mean "remove," right?   Move out implies that you are
> > moving it somewhere.   You haven't actually answered my question.  You
> say
> > that SWILD will remove the load, but you don't give any evidence of this.
>
> Yup.
>
> Earlier in the thread, one of justifications for this work was "DNS
> Noise: Measuring the Pervasiveness ofDisposable Domains in Modern DNS
> Traffic." (posted by Lanlan Pan).
> In the abstract of the same is: "Disposable domains are likely
> generated automatically, characterized by a “one-time use” pattern,
> and appear to be used as a way of “signaling” via DNS queries."
>
> The document contains some examples of these "disposable domains",
> including:
> 0.0.0.0.1.0.0.4e.135jg5e1pd7s4735ftrqweufm5.avqs.mcafee.com
>
> McAfee's site says: "GTI File Reputation looks for suspicious
> programs, Portable Document Format (PDF) files, and Android
> Application Package (.APK) files that are active on endpoints running
> McAfee products, including Endpoint Security (ENS), VirusScan
> Enterprise (VSE), and SaaS Endpoint Protection (formerly known as
> Total Protection Service). If any suspicious files are found that do
> not trigger existing signature DAT files, GTI sends a DNS request to a
> central database server hosted by McAfee Labs."
>
> Basically, the way that this works is to generate a hash (or similar)
> of an object and query that hash in the DNS -- information is returned
> encoded in the address.
> It is quite clear that McAfee could not (and would not) want to
> publish a record saying that this is a wildcard -- if they did, they
> would either mark all objects as safe, or as malicious.
>
>
> Another example is:
>
> load-0-p-01.up-1852280.mem-251379712-24440832-0-p-50.swap-236691456-297943040-0-p-44.3302068.1222092134.device.trans.manage.esoft.com
> Fascinating, but device.trans.manage.esoft.com has no incentive to
> publish a wildcard marker -- the whole purpose of this query appears
> to get data back to manage.esoft.com -- having this get answered from
> an intermediate cache would defeat this.
>
> The third example is:
> p2.a22a43lt5rwfg.ihg5ki5i6q3cfn3n.191742.s1.v4.ipv6-exp.l.google.com
> Lorenzo Colitti, Steinar, Erik Kline, Tiziana Refice have a good
> writeup of the purpose of these here: "Evaluating IPv6 Adoption in the
> Internet" -
> https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36240.pdf
> Again, these queries are being made for a reason -- it isn't that the
> senders figured "I know, let's make a DNS query for fun!!!" - they
> wanted to query for some data, or send some data -- like the abstract
> says: "“signaling” via DNS queries."
>
> In all of the above, publishing a "this is a wildcard" completely
> breaks the purpose of the queries, and so there is no incentive for
> these entities to publish such a record...
>
>
>
> >>
> >> 2) cache miss
> >> All of temporary subdomain wildcards will encounter cache miss.
> >> Query xxx.foo.com,  then query yyy.foo.com, zzz.foo.com, ...
> >> We can use SWILD to optimize it,  only query xxx.foo.com for the first
> >> time and get SWILD, avoid to send yyy/zzz.foo.com queries to
> authoritative
> >> server.
> >>
> >>
> >> Can you characterize why sending these queries to the authoritative
> server
> >> is a problem?
> >
>
> For the examples used in the paper justifying this, it's not a
> problem, it's the purpose :-)
>
> >
> > Ok, Similar to RFC8198 section 6
> > Benefit but not problem,  directly return from cache, avoid send queries
> to
> > authoritative, and wait for response, reduce laterncy.
> >
> >
> > Okay, but this isn't a reason to prefer this to existing, standardized
> > technology.
> >
> >> 3) DDoS risk
> >> The botnet ddos risk and defense is like NSEC aggressive wildcard, or
> NSEC
> >> unsigned.
> >> For example,  [0-9]+.qzone.qq.com is a popular SNS website in China,
> like
> >> facebook. If botnets send "popular website wildcards" to recursive,  the
> >> cache size of recursive will rise, recursive can not just simply remove
> them
> >> like some other random label attack.
> >> We prefer recursive directly return the IP of subdomain wildcards, and
> not
> >> rise recursive cach, not send repeat query to authoritative.
> >>
> >>
> >> Why do you prefer this?   Just saying "we prefer ..." is not a reason
> for
> >> the IETF to standardize something.
> >
> >
> > Sorry, my expression is fault.
> >
> > More details:
> > 1) All of the attack botnets were customers of ISP, sent queries to ISP
> > recursive with low rate, so all of the client's IP addresses were
> > "legitimate", could not simply use ACL.
> > 2) Normal users also visit [0-9]+.qzone.qq.com, all the the random
> queries
> > domain seems to "legitimate".
> > => The client ip addresses and the random subdomains are all in the
> > whitelist, not in blacklist.
> > 3) ISP didn't have any DNS firewall equipment ( very sad situation, but
> it
> > was true ) to take over the response of "*.qzone.qq.com".
> >
> > In this weaker scenario,  it will be better if give recursive more
> > information to directly answer queries from cache, and make recursive
> not to
> > send/cache many subdomains query/response.
> > Of course, we can defense the attack with professional operation, solve
> the
> > problem very well. But there are also many more weaker recursive only run
> > bind software, without any protection...
> >
> >
> > Maybe they should upgrade.
> >
> > I will reconsider these problems of the proposal, make the improvement
> > analysis on real-world caches before next step.
> >
> >
> > Thanks!   However, I would really encourage you to step back from your
> > proposal and see if there's a way to accomplish what you want without
> adding
> > this resource record.   I think you can get the same results you want
> > without SWILD, and the result will be a lot better for the DNS as a
> whole.
> >
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dnsop
> >
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan