On Fri, Nov 10, 2023 at 6:45 AM Denny Watson <wat...@spamhaus.org> wrote:
> On 11/10/2023, Paul Wouters wrote: > > On Fri, 10 Nov 2023, John R Levine wrote: > > > >> Subject: [DNSOP] QNAME minimization is bad > >> > >> Well, not always bad but sometimes. > > > > A bit misleading subject :P > > > >> I'd like to write a draft that updates RFC 9156 by describing > >> situations like this that caches could recognize and avoid useless > >> churn, added to section 2.3 which already suggests special casing > >> underscored labels. > > > > Couldn't the RBL's add an underscore in their base zone name to trigger > > the special casing in 9156? That would not require a new RFC and > > perhaps might not require code updates? > > There may be other things RBLs (and owners of in-addr/ip6 child zones) could do which would not require RFC changes or code changes. Whether it is feasible for RBLs may involve more questions and answers to fine-tune the suggestion to meet their needs. It may also require a bit of testing to determine behavior and feasibility versus resolvers doing 9156 minimization and 8198 aggressive NSEC. Sign the zone(s), specifically using NSEC, not NSEC3. This will allow resolvers doing 9156 and 8198 together to skip ENTs beneath nodes in the tree, and more quickly walk the tree to the leaf nodes or to discover non-matches. This should reduce the query load on the auth servers. Note that there is still room for improvement (and possibly a new RFC), by soliciting NSEC records alongside positive responses. As it stands, there needs to be a query at the name immediately beneath an existing node in the tree to obtain an NSEC record. > The current situation represents countless software packages that would > need to be reworked to accommodate a new QNAME request starting with an > underscore. It's a bit of a heavy lift. While I personally believe it > would be better to get these sorts of queries out of DNS, this again > points the the install base problem, still also a heavy lift. > > One thing that is of interest to me; There appears to be no way for the > owner of the dataset being queried (they should understand what exists > in their zones better than anyone else) to signal that beneath this > domain cut you should just request the full QNAME. > See above: signing the zone should allow skip-ahead activity, particularly in IP6 space. > > I also suspect (perhaps I missed it) that modifying the values in SOA > returned for NOERROR + NODATA would be of value for negative caching. > Again, the data owners should have a better understanding of their zones > than anyone else. > > Correct. In 8198: ... the TTL of the NSEC/NSEC3 record and the SOA.MINIMUM field... are the attributes that control behavior for aggressive NSEC usage. Those can be overridden by resolver operators, so choosing relatively moderate values may be advisable. Brian > -- > Denny Watson > Lead Investigator > The Spamhaus Project > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
