The more generalized form, of course, is for the client to provide a bitmap 
and/or an enumerated list, of the RRTYPEs it wishes to receive and/or not 
receive.

One of the sticky problems to deal with, however, is how the server should 
respond if it implements some, but not all of the RRTYPEs requested (spike the 
whole transaction with a NOTIMP? return the ones it knows about and a pseudo-RR 
representing the ones it doesn't?)

                                                                                
                        - Kevin

-----Original Message-----
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Tony Finch
Sent: Wednesday, March 23, 2016 6:32 AM
To: Marek Vavruša
Cc: dnsop@ietf.org WG
Subject: Re: [DNSOP] Introducing draft-vavrusa-dnsop-aaaa-for-free

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

Reply via email to