Hi Fujiwara-san, > I need to read ICANN's gTLD agreements. It may limit number of NS RRs.
I briefly read the current ICANN's Base Registry Agreement, but I couldn't find anything that specified a maximum number of nameservers per registered domain name. Base Registry Agreement https://www.icann.org/en/registry-agreements/base-agreement But I've find an IANA document about technical checks for DNS root zone changes published in 2006. It limits the maximum number to 13. Comments Sought on Technical Checks Used for DNS Root Zone Changes https://www.icann.org/en/announcements/details/comments-sought-on-technical-checks-used-for-dns-root-zone-changes-18-8-2006-en This specifies minimum and maximum number of name servers: > > The tests that IANA conducts today are: > > 1. Minimum number of name servers. > There must be at least two name servers supplied, > and they must not share the same IP address. > 2. Maximum number of name servers. > There must be no more than 13 name servers supplied. You may add it to your I-D as reference. -- Yasuhiro 'Orange' Morishita <yasuh...@jprs.co.jp> From: Kazunori Fujiwara <fujiw...@jprs.co.jp> Subject: [DNSOP] Re: dns-upper-limit-values-02 Date: Thu, 13 Mar 2025 18:12:17 +0900 (JST) > 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 > _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
