please help me get over the feeling that this argument is founded on the
same logic as that used by folks who "know" I might want, no NEED that
extra bit of email in my inbox. As I read it, it sounds like DNS Server
Spam being "PUSHED" to the Resolver who may or may not want the data.
Please
Status Quo is good for ipv4 to ipv6 migration.
Totally agree with william on PUSH/PULL.
1. Hotest internet service's RDATA always exists in recursive dns cache,
PUSH is not speed up much except hit-miss. ( recursive -> authority )
2. clients known what they want, PULL & prefething is Ockham's
On Wed, Aug 17, 2016 at 12:45 PM, 神明達哉 wrote:
> At Thu, 4 Aug 2016 20:03:35 -0400,
> Tim Wicinski wrote:
>
> > This starts a Working Group Last Call for draft-ietf-dnsop-resolver-
> priming
> >
> > Current versions of the draft is available here:
> >
appolgies for setting this aside for a month. IETF intervened, I don't
plan to advance this until the question is addressed in any event.
On 7/8/16 1:32 PM, Robert Sparks wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents
On 16 August 2016 at 08:57, Tim Wicinski wrote:
> All,
>
>
> In Berlin we had two presentations on different methods of returning
> multiple responses:
>
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>
>
On Tue, Aug 16, 2016 at 8:57 AM, Tim Wicinski wrote:
> All,
>
>
> In Berlin we had two presentations on different methods of returning
> multiple responses:
>
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>
>
Hello,
> From: Tim Wicinski
> In Berlin we had two presentations on different methods of returning
> multiple responses:
> All of these documents are attempting to solve a larger problem in
> different ways.
> The end result is "Return Associated Answer" to the client.
>
>
from an attacker POV, I would strongly support PUSH, as it would increase
DDoS effectiveness. The performance enhancement seems to be based on some
presumptions about servers retaining residual knowledge of the resolver
behaviours.
PULL minimizes the attack surface. wrt cache coherence and delay,
i look at much of the current work product and it reminds me of the term
"guilding the lily"...
my view of the DNS landscape is a series of concentric circles, the center
is DNS protocol fundamentals, the namespace and wire formats. outside that
are things like namespace representation, which