[NCAP-Discuss] Nearly-empty TLD zone contents (was Re: Outline of possible phases)

[Casey Deccio]

I'm going through Rubens' email and addressing different points in several emails.  This first one is about zone contents.

> On Aug 2, 2023, at 3:42 PM, Rubens Kuhl via NCAP-Discuss <ncap-discuss at icann.org> wrote:
> 
> Option 1: Delegated zone only contains SOA, dotless NS, dotless DNSKEY, NSEC records and RRSIGs for all the records.

Thanks for this great detail.  Let me share some of my thoughts with regard to the nearly-empty TLD zone file.  There are at least four considerations, one of which relates to DNSSEC-signing, which you've just shared.

1. Aggressive NSEC caching.  Where aggressive NSEC caching is in use, negative responses can be inferred by the resolver when the zone is DNSSEC-signed.  In the case of a zone that is empty other than its apex, we would expect to get *no* follow-up queries from a resolver that is doing aggressive NSEC caching, i.e., because it will have learned the entire contents of the zone, it has no need to query again.

2. NXDOMAIN: There Really Is Nothing Underneath.  Suppose a resolver receives a query for foo.applied-for-tld-string.  It issues that query to auth server, and receives NXDOMAIN.  A short time later, the resolver receives query for bar.foo.applied-for-tld-string.  What does the resolver do?  Well, according to RFC 8020:

   Many resolvers today will forward both queries.
   However, following the rules in this document ("NXDOMAIN cut"), a
   resolver would cache the first NXDOMAIN response, as a sign of
   nonexistence, and then immediately return an NXDOMAIN response for
   the second query, without transmitting it to an authoritative server.

(source: https://www.rfc-editor.org/rfc/rfc8020)

3. Qname minimization.  If a resolver receives a query for foo.bar.applied-for-tld-string, a qname-minimizing resolver will query the authoritative server for bar.applied-for-tld-string.  When it receives an NXDOMAIN response, it *may* stop querying right there because it has learned that there is nothing beneath bar.applied-for-tld-string.  In that case, the auth server never sees the full qname.

4. TTL.  With previous analyses, the only TTL involved is that of the SOA record (and negative cache value of that record) of the root.  That value is current 86400, which means that a resolver receiving an NXDOMAIN for foo.applied-for-tld-string can potentially wait for an entire day before querying again for foo.does-not-exist.  However, we had no control over that value before.


Three things can help with mitigating these behaviors and maximizing the telemetry at the auth servers.

1. I believe that the TLD should be *unsigned*.  No DS (in parent), DNSKEY, RRSIG, or NSEC(3) records.  This addresses the negative aggressive caching issue (#1).

2. When we delegate a nearly-empty TLD zone, we now have control over the TTL knob for that TLD.  By using a shorter TTL, we can mitigate the effects of caching at the resolvers, including NXDOMAIN caching (#2), but also aggressive NSEC caching (#1).  With some resolvers (that ask the full qname regardless), this might even help with qname minimization (#3).  This means we get a better look at both query names and quantities that the resolver is seeing.  Of course, this comes at the cost of potentially bearing more load, but I expect that we can handle that given the fact that these are (otherwise) nonexistent TLDs, so their demand is not as high as that of existing TLDs.

3. Finally, to more fully address the issue of qname minimization (#3) -- for which a low TTL might not help -- here is a new idea to help see the full qname where it would otherwise be lost on qname-minimizing resolvers that follow the NXDOMAIN principles in RFC 8020.  We add a wildcard HINFO record to the zone.  This would make it so that queries for foo.applied-for-tld-string would result in NOERROR (empty answer) instead of NXDOMAIN, which means that the resolver has no choice but to query again for  bar.foo.applied-for-tld-string, even if it strictly follows the RFC 8020 principles.  Note that this is inspired by RFC 8482, where HINFO is used for minimal ANY responses, but it is applied here for a different purpose.

Here is the resulting zone, with 1) no DNSSEC, 2) 60-second TTL and negative cache TTL, and 3) the use of an HINFO record:

Example (60-second TTL):

$TTL	60
@	IN	SOA	localhost. root.localhost. (
			      1		; Serial
			 3600		; Refresh
			 3600		; Retry
			86400		; Expire
			 60 )			; Negative Cache TTL
@	IN	NS	ns1.trial-delegation.icann.org.
@	IN	NS	ns2.trial-delegation.icann.org.
*   HINFO "" ""

I know that the HINFO record idea is new, and there might be some concerns with that.  It is still a negative response (NXDOMAIN vs. NOERROR).  Like anything else proposed, this has to do with the risk/reward we are looking for.

Casey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/ncap-discuss/attachments/20230816/a39396ce/attachment.html>