[dns-operations] 答复: [dns-operations] More Aggressive prefetch for popular names

[Davey Song(宋林健)]

If frequent prefetching generating annoying traffic is the main cause, we
can reduce it dramatically by setting up hidden slave on resolver side
receiving notify from the popular name owner’s master server. The urgent
changes are fetched only when the slave got a notify. It requires m-to-n
cooperation relationship between invited resolver operators and
authoritative operators, so it sounds like it does not scale well but works
in a small number of popular names and popular resolvers

 

Guys, do you think it sounds like a plan ?

 

Davey

 

发件人: dns-operations [mailto:dns-operations-bounces at dns-oarc.net] 代表
Davey Song(宋林健)
发送时间: 2019年4月5日 9:19
收件人: 'dns-operations'
主题: [dns-operations] More Aggressive prefetch for popular names

 

Hi folks, 

 

I’m writing to ask if any resolver operator is doing or be asked to do
aggressive pre-fetch for popular names in the case of urgent changes of
owners’ names. 

 

The problem space is some concerns and complains on DNS TTL which usually
makes mis-configured or hacked RR stick around for long time than name owner
expected. TTL 1 ~2 day even hours will make huge damage (if the user based
are large) and the name owner can do nothing about it but wait unless the
DNS resolver can be notified to fix it.

 

I do know the context of draft-wkumari-dnsop-hammer (thanks to Mukund’s
reminder,) but it is not aggressive enough. It pre-fetch only when it is
close to the end of TTL. The intuitive approach to address the problem in my
mind is to prefecth the popular names every 30 seconds or less on popular
resolvers. The performance optimization can be done using a separate special
server other than the busy resolver.

 

I wonder If it was discussed before or any obstacle exist which make this
problem unresolved. Or any performance and risk tradeoff there. Thanks in
advance.

 

Best regards, 

Davey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20190405/af234984/attachment.html>