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

[Warren Kumari <[e-mail]>]

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