At Mon, 29 Feb 2016 16:54:28 +,
Warren Kumari wrote:
> > - Section 1
> >
> >The title of this draft comes from a famous Monty Python skit - "The
> >Cheese Shop". There are some useful parallels between this problem
> >and the skit - watching the skit is encouraged to understand t
On Fri, Feb 26, 2016 at 7:05 PM 神明達哉 wrote:
> At Thu, 25 Feb 2016 04:58:11 +,
> Warren Kumari wrote:
>
> > We have recently updated "Believing NSEC records in the DNS root" (
> > https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).
> >
> > This incorporates some comments, but als
On Saturday, February 27, 2016 6:53:04 PM PST Philip Homburg wrote:
> ...
> ANC can have immediate local benefits if it reduces the cost of running a
> resolver or if the performance of the resolver is noticeably better.
> ...
in an attack scenario (random subdomain for example) there would be a
>dnssec, ipv6, sav, anc, and a lot of other follow-on technologies, are
>not make-money proposals, nor save-money proposals. it makes absolutely
>zero business sense to do any of it unless you can be a late adopter
>after others have (stupidly and/or selflessly) created a market for you.
To me,
> i believe there's a section missing in RFC's, after IANA CONSIDERATIONS
> and SECURITY CONSIDERATIONS. we need to specify ECONOMIC CONSIDERATIONS
> and expose feel-good proposals as what they obviously are, so that only
> those with long term public good as their motive know to pay attention.
I
Ted Lemon wrote:
sadly, this same engineering economic argument applies to SAV.
Do you mean that aggressive nsec in the cheese shop (which is now my
epithet for the root, apparently) is as important as SAV?
no. only that the benefit of doing either ANC (aggressive negative
caching, which w
So your draft may want to clearly state whether the type of caching that
it proposes should be treated as a negative or a positive response. I can
see a good case being made for either. Or maybe it doesn't matter much and,
as you say, the implementor can choose.
For the root, the NSEC and SOA
> On Feb 26, 2016, at 5:02 PM, Warren Kumari wrote:
>
For implementations that treat "positive" and "negative" cache entries
separately, perhaps the document should say whether a validated proof of
non-existence should be considered "positive" or "negative."
>
>
> I think that i
> sadly, this same engineering economic argument applies to SAV.
Do you mean that aggressive nsec in the cheese shop (which is now my epithet
for the root, apparently) is as important as SAV?
The sad irony of SAV of course is that everybody would benefit from everybody
else doing it, but nobody
Ted Lemon wrote:
Please say more about the "security risk". I'm missing it.
Ideally you want your cache code to be as simple as possible. More
code means more bugs.
for features with local benefit (dnssec validation for example) this is
a cost:benefit tradeoff worth making. for those with
> Please say more about the "security risk". I'm missing it.
Ideally you want your cache code to be as simple as possible. More code means
more bugs.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[I accidentally hit "Reply", not "Reply all" earlier, and sent the
below just to Duane. (mentioning because I cut and pasted into this
email, and it may have mucked up quoting / formatting ]
On Thu, Feb 25, 2016 at 6:25 PM Wessels, Duane wrote:
>
>
> > On Feb 25, 2016, at 3:12 PM, John R Levine
At Thu, 25 Feb 2016 04:58:11 +,
Warren Kumari wrote:
> We have recently updated "Believing NSEC records in the DNS root" (
> https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).
>
> This incorporates some comments, but also does a better job of explaining
> the technique, what the
On Thu, Feb 25, 2016 at 10:34 AM Paul Hoffman wrote:
> On 25 Feb 2016, at 10:18, Ted Lemon wrote:
>
> > I'm sorry to be a sticky wicket here, but I have to ask: have you
> > thought about what a guaranteed-correct implementation of this would
> > look like? I think you need to actually do that
> On Feb 25, 2016, at 3:12 PM, John R Levine wrote:
>
>> In other words, today (as a BIND user) you might only have to wait 3 hours
>> when a new TLD is added, not the whole SOA minimum.
>
> Given that new TLDs publish a 127.53.53.53 wildcard for a month to try and
> show people where they hav
In message , "Paul Hoffman" writ
es:
> On 25 Feb 2016, at 12:20, Ted Lemon wrote:
> > You query for "l". The authority gives back "!kk->m" and "!@->aa".
> > How should you update your state as a resolver? The !ll->mm and
> > !kk->m rules are mutually inconsistent. Do you store inconsistent
In other words, today (as a BIND user) you might only have to wait 3 hours
when a new TLD is added, not the whole SOA minimum.
Given that new TLDs publish a 127.53.53.53 wildcard for a month to try and
show people where they have collisions, I'd think the root's one day TTL
would be the least
> How can one argue with logic like that? (That's a serious question.)
I know, it sucks.
> If a protocol requires DNSSEC (which more are these days), then only
> systems that have DNSSEC can implement them. That's an operational
> choice.
Yes. But the case where aggressive NSEC caching works a
> On Feb 25, 2016, at 2:17 PM, John Levine wrote:
>
>> You query for "m" ...
>
>> Meanwhile, at the authority, "m" is added and "ll" is deleted. ...
>
>> You query for "l". ...
>
>> Meanwhile at the authority, everything but @ is deleted.
>
> This doesn't strike me as a very persuasive argum
On 25 Feb 2016, at 12:20, Ted Lemon wrote:
Saying "without DNSSEC" doesn't seem like a better way to address any
problem...
Depends on how far in front of the horse you want to put the cart, I
guess. By "without DNSSEC," I mean "without requiring DNSSEC." Of
course we want DNSSEC, but it
>You query for "m" ...
>Meanwhile, at the authority, "m" is added and "ll" is deleted. ...
>You query for "l". ...
>Meanwhile at the authority, everything but @ is deleted.
This doesn't strike me as a very persuasive argument. The DNS is not
Oracle, and has never promised to be perfectly coher
In message <8d23d4052abe7a4490e77b1a012b630797a31...@mbx-03.win.nominum.com>,
Ted Lemon writes:
> > Saying "without DNSSEC" doesn't seem like a better way to address any
> > problem...
>
> Depends on how far in front of the horse you want to put the cart, I
> guess. By "without DNSSEC," I mean
> Saying "without DNSSEC" doesn't seem like a better way to address any
> problem...
Depends on how far in front of the horse you want to put the cart, I guess.
By "without DNSSEC," I mean "without requiring DNSSEC." Of course we want
DNSSEC, but it's not widely enough deployed yet to really
On Thu, Feb 25, 2016 at 1:36 PM, Paul Hoffman wrote:
> On 25 Feb 2016, at 10:32, Ted Lemon wrote:
>
> An additional point about this: the case where the cheese shop solution
>> works is really the case where large service provider DNS caches do the
>> aggressive caching. In this case we can get
On 25 Feb 2016, at 10:32, Ted Lemon wrote:
An additional point about this: the case where the cheese shop
solution works is really the case where large service provider DNS
caches do the aggressive caching. In this case we can get the same
benefit without DNSSEC by simply keeping a complete
On 25 Feb 2016, at 10:18, Ted Lemon wrote:
I'm sorry to be a sticky wicket here, but I have to ask: have you
thought about what a guaranteed-correct implementation of this would
look like? I think you need to actually do that analysis before we
proceed with this.
Can you say more? It seems
-boun...@ietf.org] on behalf of Ted Lemon
[ted.le...@nominum.com]
Sent: Thursday, February 25, 2016 13:18
To: Warren Kumari; dnsop
Subject: Re: [DNSOP] Updated cheese-shop: cost/benefit analysis, please?
I'm sorry to be a sticky wicket here, but I have to ask: have you thought about
what a guarante
alyze this problem before considering
proceeding with either this proposal or the other.
From: DNSOP [dnsop-boun...@ietf.org] on behalf of Warren Kumari
[war...@kumari.net]
Sent: Wednesday, February 24, 2016 23:58
To: dnsop
Subject: [DNSOP] Updated cheese-shop.
root zone size is much smaller than TLD, and RR has long ttl.
NSEC is satisfied.
Warren Kumari 于2016年2月25日周四 下午12:58写道：
> Dear DNSOP,
>
> We have recently updated "Believing NSEC records in the DNS root" (
> https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).
>
> This incorporates s
>For these reasons we think that it is worth pursuing this in parallel
>with Fujiwara-san's "Aggressive use of NSEC/NSEC3" document.
>cheese-shop does not conflict with "Aggressive use...", rather it
>complements it, and can demonstrate the technique (in this restricted use
>case).
>
>We welcome a
Dear DNSOP,
We have recently updated "Believing NSEC records in the DNS root" (
https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).
This incorporates some comments, but also does a better job of explaining
the technique, what the benefits are, and why we are only handling the
special
31 matches
Mail list logo
