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

[Lanlan Pan <[e-mail]>]

Thanks a lot for your detail analysis, :-)

Ralf Weber <[e-mail]>于2017年8月17日周四 下午11:16写道：

> Moin!
>
> On 17 Aug 2017, at 0:09, Lanlan Pan wrote:
> > Yes, I agree, in fact the *online cache rate* is small (0.12% queries),
> LRU
> > & TTL works fine.
> > SWILD not save many online cache size, because of the queries rate.
> > And Temporary Domain Names/ All Names: 41.7% for 7 days statistics,  the
> > rate can be about 10% for 1 day statistics. Because temporary domain
> names
> > expire after TTL time.  Ralf has similar curious.
> As you mention me, with the data you supplied it is highly unlikely that a
> lot of records will still be active in the Cache because of the TTL and
> how least recently used (LRU) algorithms work.
>

> > The problem is:
> >
> > 1)  cache size
> > Recursives commonly cache "all queried domain in n days" for some
> > SERVFAIL/TIMEOUT condition, which has been documented in
> > https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01
> That is not what the draft suggest and is not what the current
> implementations of this or similar features do. They all rely on a cache
> with a fixed size and if the record that normally would be expired is
> still in the cache extend it's lifetime when queried. The records you
> mention are not queried and thus would be expired because other records
> that are queried more frequently would have overwritten them anyway.
>
> There also is nearly no harm if these queries fail in case the
> authoriative is not responding as most of those queries you describe
> are computer and not human generated. The draft above and similar
> techniques where done because of the twitter.com problem. Now I can
> assure you that twitter.com will always be hot (asked at least every
> couple of seconds) in a regular resolver at your ISP or a provider
> of DNS services, and thus the expired record will probably still be
> in the cache.
>
You are totally right.
I admit the online cache size is not a problem on fixed size LRU/TTL
refresh.

>
> > The subdomain wildcards cache are needlessly,  we can use heuristics
> > algorithm for deciding what to cache, or just use simple rule like
> "select
> > domain which queies time > 5 in last n days".
> > We can use SWILD to optimize it, not need to detecting, just remove items
> > which SWILD marked, to save cost.
> The cost of sending a query now and then is very low resolvers do that all
> the time and the rate on which they have to do that is very low. However to
> actually save costs you would have to deploy your proposal on the
> authoritative server that have that behaviour and the resolvers. Good luck
> with that. I also assume some of the authorities are actually interested in
> the queries so they would not implement your proposal even if they could,
> making the theoretical improvement of 0.12% even smaller.
>
0.12% is the rate of recursive queries times.
authorities's improvement rate is not 0.12%, it depends on the query
distribution of subdomain wildcards on the whole zone, and the number of
recursives that enable SWILD.

>
> > 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.
> See above.
>
same as above, and the above reply to Ted, :-)

>
> > 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.
> As PRSD (Pseudo Random Subdomain) attacks as I call them or waterfall
> attacks
> as others call them are usually asking every subdomain once (and these
> botnets
> take great care on doing this) the record would be removed by the least
> recently used (LRU) algorithm when other records that are used more are
> questioned.
>
> While these attacks on recursive resolvers can stress the recursive to
> authoritative part of the resolver there are techniques to limit the
> exposure to clients. I did gave a talk on that at DNS-OARC 2015 Spring
> Workshop in Amsterdam on that topic:
>         https://indico.dns-oarc.net/event/21/contribution/29
> and the summary of it is that all major vendors of recursive resolvers
> handle this, so again while your solution would be one once universally
> deployed there are already solutions to the problem out there, so why do
> another one?
>
See also the above reply to Ted.
All major vendors of recursive resolvers can deal "legitimate subdomain
wildcards" problem with some feature like Response Rate Limiting.
The difference of my solution is directly reply IP to all "legitimate"
clients' low rate queries, not move in/out the subdomain wildcard records
with LRU.

So long
> -Ralf
>
>
> --
致礼  Best Regards

潘蓝兰  Pan Lanlan