Marek Vavruša <mvavr...@cloudflare.com> wrote:
>
> 1. No signalling to client when AAAA is unavailable
>
> I didn't want to include it in the beginning but I see it has a merit.
Yep. Also, while improving this for direct address queries, it should also
be improved for additional data in MX, NS, SRV (etc.) queries.
> DNSSEC has means to provide authenticated non-existence for free, so I
> think it's worth for auth server to add either data or non-existence proof
> for any applicable RR.
> e.g. if it has AAAA, but not A, it would provide AAAA RRs and NSECX for A;
> if it has A but not AAAA, it would provide A RRs and NSECX for AAAA
>
> For legacy case of no DNSSEC, an SOA in the authority indicates that no
> record matching QNAME+QTYPE exists, but can't effectively signalise
> non-existence of the additional address records. Which is not great, but
> I'm not in for legalising yet-another EDNS option, and it also would
> require client to signalise that it can handle such option before an auth
> server raises it in the answer.
Another option might be to define a couple of meta-TYPEs, NOA and NOAAAA
(same RDATA format as NULL), so the server could say, "I wanted to put
AAAA records here, but there aren't any, and there isn't a DNSSEC pone
either".
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode
Forties: Variable 3 or 4, becoming southwest 4 or 5 later. Slight or moderate.
Occasional drizzle. Good, occasionally poor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
