Dear Yorgos san, Thanks very much.
> For the authoritative side I believe there needs to be a distinction > between primaries and secondaries. > Primaries can refuse to load the zone when limits are surpassed but > secondaries are garbage-in/garbage-out most of the time. I agree. need to add text. > The wording "desirable upper limit" and the low values on the table in > section 5 caught me off guard. > Could I suggest that it is renamed to "observed max value"? > Unless I completely misunderstand the concept. > Which I may do as I see "number of CNAME/DNAME chains" with a value of > 1. I intended "Desirable upper limit" to be the value recommended as a good DNS setting. Is there a better term? > I also understand that no value in the "hard limit" column means > unlimited. Would it be better to explicitly say there are no limit ? > - DNS message size; I don't think we can/should limit that at all. This > will kill the inovation part and/or PQC, Yes. I agree. > - number of RRs in an RRSet; this can be limited to a few hundreds I > suppose, a hundred is too large, I think. but many domain names use too many TXT RRs. > - number of NS RRs and number of glue RRs in a delegation; I believe we > need to do some research before imposing the root's operation as a > hard limit, I checked com/net/org/info/biz zones and find max 13 NS RRs for each delegation. I need to read ICANN's gTLD agreements. It may limit number of NS RRs. > - number of RRSIG RRs for each name and type; quick note about Unbound > and MAX_VALIDATE_RRSIGS for the discussion. This is the maximum number > of RRSIGs that Unbound will try to validate. They can still be more > RRSIGs there that Unbound will ignore if it doesn't understand them > because of the algorithm used for example. We need to do some research > for the actual number here. Especially with the upcoming multisigner > scenarios. Thanks. I will update text. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > From: Yorgos Thessalonikefs <yor...@nlnetlabs.nl> > Dear Fujiwara-san, > > I find the idea of the draft very useful especially as an implementer. > > I understand the argument that I often hear that DNS has allowed > innovation because there are no limits. > I also hear that implementers should take the advice of 1035 and apply > limits to work done if an RFC does not set them explicitly. > > These seem to contradict themselves because different implementations > choose different hand-wavey limits and that has proven to be non > interoperable. > One such example is CNAME chains. > > So I am very much in favor of introducing universal, documented limits > on DNS and looking forward to the discussion. > > Some comments on the draft's text: > > For the authoritative side I believe there needs to be a distinction > between primaries and secondaries. > Primaries can refuse to load the zone when limits are surpassed but > secondaries are garbage-in/garbage-out most of the time. > > The wording "desirable upper limit" and the low values on the table in > section 5 caught me off guard. > Could I suggest that it is renamed to "observed max value"? > Unless I completely misunderstand the concept. > Which I may do as I see "number of CNAME/DNAME chains" with a value of > 1. > > I understand that hard limit is the only limit that matters, the one > imposed by resolvers (and primaries, but resolvers are the ones that > matter in my opinion). > I also understand that no value in the "hard limit" column means > unlimited. > > With that I would like to comment on: > - DNS message size; I don't think we can/should limit that at all. This > will kill the inovation part and/or PQC, > - number of RRs in an RRSet; this can be limited to a few hundreds I > suppose, > - number of NS RRs and number of glue RRs in a delegation; I believe we > need to do some research before imposing the root's operation as a > hard limit, > - number of RRSIG RRs for each name and type; quick note about Unbound > and MAX_VALIDATE_RRSIGS for the discussion. This is the maximum number > of RRSIGs that Unbound will try to validate. They can still be more > RRSIGs there that Unbound will ignore if it doesn't understand them > because of the algorithm used for example. We need to do some research > for the actual number here. Especially with the upcoming multisigner > scenarios. > > In general, for the "number of $things" in a packet categories, I > would like to see an observed current operational max value and a hard > limit to roughly double that number. > It could still leave space for innovation, restrict the presence of > thousands of $things, and could be revisited in the future if we ever > need to bump that value up. > > As for proceeding, if the working group finds this useful, > implementers can fish for other limits in their codebases and enrich > the recommendation table. > That will benefit homogeneous DNS resolution. > > Personally I would like to see such a document advance and a flag day > for resolver implementers. > > Specifically for implementers it will free a lot of time from > responding to resource exhaustion attacks on DNS and "but that other > resolver works" arguments. > > Best regards, > -- Yorgos > > On 04/03/2025 10:45, Kazunori Fujiwara wrote: >> Dear dnsop WG, >> I submitted draft-fujiwara-dnsop-dns-upper-limit-values-02 >> Upper limit values for DNS. >> URL: >> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-dns-upper-limit-values/ >> - added "Desirable upper limit", "hard limit", "protocol limit", >> (existing) implementation limit. >> - added text about problems about too many/deep use of unrelated name >> server names. >> - added: "DNS software is expected to make these items configurable >> parameters that operators can control." >> I'm currently unsure how to proceed. Is the draft useful ? >> I'd like to hear comments from DNS implementers >> who have actually implemented upper limits. >> Regards, >> -- >> Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> >> _______________________________________________ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org > > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org > _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
