On 09/07/2024 11:06, Kazunori Fujiwara wrote:
Dear DNSOP,
I submitted new draft that proposes to consider "Upper limit value
for DNS". If you are interested, please read and comment it.
I disagree with the rationale for 13 name servers.
The root (and .com) have that because it was what wou
On 10 Jul 2024, at 11:22, Ray Bellis wrote:
> On 09/07/2024 11:06, Kazunori Fujiwara wrote:
>> Dear DNSOP,
>> I submitted new draft that proposes to consider "Upper limit value
>> for DNS". If you are interested, please read and comment it.
>
> I disagree with the rationale for 13 name servers.
Reviewer: Nicolai Leymann
Review result: Ready
I am the designated DNS Directorate reviewer for draft-ietf-dnsop-zoneversion.
This is the forth review I am doing - in my last reviews on the -08 and -09
versions I
came to the conclusion that the document is ready for publication.
The draft is g
> I disagree with the rationale for 13 name servers.
>
> The root (and .com) have that because it was what would fit into
> packets of a particular size given their naming scheme and that
> scheme's efficient compressibility.
>
> If there is to be a recommended limit, it should be specifically
>
On 10/07/2024 15:27, Philip Homburg wrote:
So the question becomes, do we want some limits in an RFC that everybody
agrees on or do we want to keep the current informal system where limits
are not fixed and people can get unlucky if they exceed limits they didn't
know exist.
I do find the possi
> On 10 Jul 2024, at 14:27, Philip Homburg wrote:
>
> So the question becomes, do we want some limits in an RFC that everybody
> agrees on or do we want to keep the current informal system where limits
> are not fixed and people can get unlucky if they exceed limits they didn't
> know exist.
I
Hi,
since draft-fregly-dnsop-slh-dsa-mtl-dnssec-02 and
draft-harvey-cfrg-mtl-mode-03 have
been published now, I would like to discuss something I noticed when this was
first brought
to my attention during IETF in Prague.
The Section 6.2 says:
> As described in 9.2 of [I-D.harvey-cfrg-mtl-mode]
On 10/07/2024 14:27, Philip Homburg wrote:
So the question becomes, do we want some limits in an RFC that everybody
agrees on or do we want to keep the current informal system where limits
are not fixed and people can get unlucky if they exceed limits they didn't
know exist.
I'm all for a re
Fujiwara san,
On Tue, Jul 09, 2024 at 07:06:27PM +0900, Kazunori Fujiwara wrote:
> Dear DNSOP,
>
> I submitted new draft that proposes to consider "Upper limit value for DNS".
> If you are interested, please read and comment it.
Some of the recent CVEs to do with excessive processing can indeed
Hi Mukund,
On 10/07/2024 16:57, Mukund Sivaraman wrote:
The current DNS protocols have been able to evolve so well since 1987
because of their flexibility. I suggest that limits be left to
implementations rather than be set in stone in RFC. It could result in
surprises when DNS data is extra-ord
> On Jul 10, 2024, at 3:09 AM, Nicolai Leymann via Datatracker
> wrote:
>
> The draft is going to be published as Informational RFC. The document is well
> written and defines an EDNS option which can be used for debugging purposes.
Thank you for the review!
Note that as of -09 the intended
Thanks for the reference Gio (and Raffaele who also pointed this out to me),
We're citing your paper now in our work-in-progress copy (see
https://github.com/shuque/ns-revalidation/commit/5e52689 ), so it will
be part of the next version.
-- Willem
Op 08-07-2024 om 12:55 schreef Giovane C. M
On Wed, Jul 10, 2024 at 05:10:47PM +0200, Yorgos Thessalonikefs wrote:
> Hi Mukund,
>
> On 10/07/2024 16:57, Mukund Sivaraman wrote:
> > The current DNS protocols have been able to evolve so well since 1987
> > because of their flexibility. I suggest that limits be left to
> > implementations rath
I see several different directions this could go that might be useful.
1. "DNS at the 99th percentile"
Rather than normatively declare limits on things like NS count or CNAME chain
length, it would be interesting to measure behaviors out in the real world.
How long can your CNAME chain be befo
>I see several different directions this could go that might be
>useful.
>
>1. "DNS at the 99th percentile"
>
>Rather than normatively declare limits on things like NS count
>or CNAME chain length, it would be interesting to measure
>behaviors out in the real world. How l
On Jul 10, 2024, at 1:03 PM, Philip Homburg wrote:
I see several different directions this could go that might be
useful.
1. "DNS at the 99th percentile"
Rather than normatively declare limits on things like NS count
or CNAME chain length, it would be interesting to measure
behav
> On 10 Jul 2024, at 9:23 AM, Ben Schwartz
> wrote:
>
> I see several different directions this could go that might be useful.
>
> 1. "DNS at the 99th percentile"
> ...
> 2. "DNS Lower Limits"
>
> ...
> 3. "DNS Intrinsic Limits"
>
> ...
> 4. "DNS Proof of Work"
> ...
The 99th percent
> From: Ray Bellis
> I disagree with the rationale for 13 name servers.
>
> The root (and .com) have that because it was what would fit into
> packets
> of a particular size given their naming scheme and that scheme's
> efficient compressibility.
Yes, I know where the "13" came from.
The BCP doc
> Even RFC 1034 says "Bound the amount of work", but explicitly
> prescribed numbers in an RFC may end up being arbitrary.
>
> When there is a difference between something working well and not
> working well, it may either be due to too much work (too much NS
> lookup indirection for example) or i
>A resolver can return TC=1 for all UDP queries if it wants, and
>this is often discussed as a DoS defense mechanism. Returning
>TC=1 for 1% of queries should not be a serious problem for
>anyone.
It seems like a very interesting experiment. Just set TC=1 after
8 CNAMEs. I think s
20 matches
Mail list logo
