> However, it doesn't make sense to include step 4. A DNSSEC validator will > have taken care of step 4.
Partially. I believe the DNSSEC validation and following the CNAME-chain have to be implemented in the same routine. This is because to perform an authenticated denial of existence, you first need to know which name and rrtype you want to prove does not exist. Say you were querying for A-type records under a.x.example.com. A valid response would be an NXDOMAIN containing a CNAME (perhaps generated from an included and authenticated DNAME) to a.y.example.com, followed by some NSEC records proving the absence of a.y.example.com. I would expect a minimal validator to 1. Look for A records under a.x.example.com, finding none 2. Look for CNAME records under a.x.example.com, finding one pointing to a.y.example.com, and authenticating it using the DNAME and associated RRSIG records. 3. Look for A records under a.y.example.com, finding none 4. Look for CNAME records under a.y.example.com, finding none 5. Verify that there really were no A, CNAME or DNAME records under a.y.example.com using the provided NSEC records. In some cases (especially with recursive resolvers) this might even involve further queries to nameservers if some expected records were not found or for whatever reason. E.g. unbound would perform steps 1 and probably 2 above, then query for another A record under a.y.example.com, even if it was already included in the first response. This makes it quite hard to separate the relevance check from the DNSSEC validation. - Thomas _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
