Re: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/proof of non-existence of the ANAME record

[Richard Gibson <[e-mail]>]

When an authoritative server receives a request with QTYPE=AAAA (without 
loss of generality with respect to A or any future ANAME-affected 
address record) for a domain name in a signed zone, there is either a 
relevant ANAME or there is not.

In the case where there a relevant ANAME, the server should include it 
with covering RRSIG(s) in the Additional section and AAAA records 
(whether static or derived from the ANAME) with covering RRSIG(s) in the 
Answer section. Intermediate servers may not replace the Answer section 
records with their own ANAME-derived data unless they can either cover 
them with valid RRSIG(s) or are responding to their own client without 
DNSSEC.

In the case where there is no relevant ANAME, which is currently always 
the case, I don't think the server is under any obligation to make 
claims about records that could have affected the response if they 
existed. Its response should include RRSIG(s) proving either the 
authenticity of the AAAA RRSet or its nonexistence (as appropriate).

On 5/29/19 03:52, Klaus Malorny wrote:
>
>
> Hi all,
>
> while still struggling with the basic ANAME processing (as described 
> in my other mail), I wondered whether with DNSSEC, an authoritative 
> name server MAY, SHOULD or MUST prove the non-existence of an ANAME 
> record when it receives an A or AAAA query and no sibling ANAME record 
> exists for the delivered address records.
>
> My personal opinion is that there is no big harm if a 
> man-in-the-middle silently removes the ANAME record from the response, 
> as the returned address records should still point to some valid 
> hosts, so I would not include it. In the case that there are neither 
> address records nor an ANAME, the NSEC/NSEC3 record which covers the 
> non-existing address record would also cover the ANAME, so this case 
> is not a problem at all.
>
> Nevertheless, I wanted to bring this to your attention just in case 
> that you haven't considered that already (it is not clear from the 
> spec that you did).
>
> Regards,
>
> Klaus
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=PUSMRyGtOXnqCa18KWsTXNcKZ2vsDfzkAaUWJLf9W18&s=jB7ql9ejEIrE_BQZMnZT83PY05rG6hg0nrmQxbrhiwU&e= 
>