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 has
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,
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.
>
> The question is start
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/
>
> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-
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/
>
> https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtype
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
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:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-priming/
>
> Please review the draft and offer re
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:
> > https://datatracker.ietf.org/doc/draft-ietf-
At Wed, 17 Aug 2016 13:03:31 -0400,
Bob Harold wrote:
> > - Section 2
> >
> >Therefore, it is important that resolvers be able to cope with
> >change, even without relying upon configuration updates to be applied
> >by their operator.
> >
> > If we really want to make it work "even
At Wed, 3 Aug 2016 13:32:56 -0700,
Warren Kumari wrote:
> We have updated this document with comments and feedback from Berlin.
> We have also gone through and done another editing pass, removing a
> significant amount of text which was intended to drive the discussion,
> but would not really be
A new meeting session request has just been submitted by Tim Wicinski, a Chair
of the dnsop working group.
-
Working Group Name: Domain Name System Operations
Area Name: Operations and Management Area
Session Requester: Tim Wicinski
Numb
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 R
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 advi
13 matches
Mail list logo
