Clarification regarding empty non-terminals (RFC 8020) about groot HOT 4 CLOSED

Hi, @jonasbb ,

Thanks for bringing this case to our attention. We are glad that a DNS researcher took an interest in the paper and read through it, including the appendix.

As you said, the formal model currently returns NXDOMAIN instead of NOERROR and no data (i.e., ⟨Ans, ∅⟩). A way to fix it is to change the Rank definition and add another case for RRLookup.
Rank would have to be a five-tuple where the first entry 𝓘 (Match(r, q)) has to be replaced by two entries, 𝓘 (ExactMatch(r, q) ) and 𝓘 (WildcardMatch(r, q) ∨ ProperPrefix(r, q)).

• ExactMatch(r, q) would be the case when the query and resource record has exactly the same domain name (dn(r) = dn(q)).
• WildcardMatch(r, q) would be the case if the query matches the wildcard record (dn(𝑞) ∈∗ dn(𝑟))
• ProperPrefix(r, q) would be the case if either the domain name of the query is a proper prefix of the domain name of the resource record or the other way too(dn(r) < dn(q) ∨ dn(q) < dn(r))

RRLookup will have another case with ⟨Ans, ∅⟩ if dn(q) < dn(R).

I believe this would fix the issue and does not alter the answer to other combinations of resource records. Please, let us know if you find any other such scenarios. We will be happy to chat if you are looking to expand the model to cover more types or even DNSSEC. We will also appreciate any feedback if you tried the tool.

from groot.

Hi @SivaKesava1,
that seems to work as far as I checked.

Another option could be to forbid ENT in the well-formedness check for zones. This could also help with a DNSSEC extension as NSEC records have trouble with ENTs since there is nothing they can sign.

I know that some authoritative DNS operators went this route. They create a synthetic TXT record with a message like "ENT" or "RFC 8020". This avoids the issue of ENTs completely and makes DNSSEC easier as now there is a record which can be signed and which can have the appropriate negative proofs too.

If you want to ensure that the answers of the model do not change due to this, you could maybe use a type which can only occur in records but cannot be used in a query. This should be enough for the case without DNSSEC.

from groot.

Thanks for checking and for the insights too about DNSSEC.
Using a type that can occur only in records is also a good idea to fix the ENTs case.

from groot.

Hi @jonasbb,

We have updated the paper to handle empty non-terminals as per the RFCs and using a type that can occur only in records. The fix that I suggested earlier will create issues for the glue records one, so we decided to use an extra type. The updated paper is available here.

from groot.