[dns-operations] resimprove and Re: DNS Flush Protocol

[Edward Lewis]

On 3/30/15, 19:07, "Paul Vixie" <paul at redbarn.org> wrote:

>if you want something that we can reach consensus on, that will be a
>recommendation, and will be a protocol ("if you want to do this, here's
>how to do it interoperably") then that will take at least "many more
>years" if it's even possible, which i doubt.

Because "protocol" can be taken to mean "rules governing an interaction"
or "DNS"...

I see no way in the DNS protocol to define a cache flush mechanism.
Regardless of the speed of deployment, which speaks to motivation, the DNS
architecture is a "pull" client-server, not a "push."  (NOTIFY seeming to
be an exception, but it isn't.  Its a case of the client and server role
being reversed compared to the AXFR and IXFR servers.  NOTIFY doesn't
cause the zone to be pushed, it tickles the XFR server to pull.)  Fudging
in a push notification ("please flush this entry from your cache") isn't
tractable.

(Yes, with time and money anything is possible.)

A successful approach (I've seen candidates for quite a while[0]) would
take advantage of the current toolset features (like the one I've used,
ISC's BIND rndc's) to flush entries.  The question then is how are these
features tickled, with authenticated authorization in mind.

I just don't see using the parent TTL's as a way to go.

[0] - This comes to mind
<https://indico.dns-oarc.net/event/13/contribution/7/material/slides/0.pdf>
, Rod's presentation at 2010 DNS-OARC.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150331/ba4ef8d7/attachment.bin>