On Mon, 3 Jul 2017, Dave Lawrence wrote:
This is just a "keep alive" so as to keep this draft in consideration as
one of the multiple solutions in this problem space while DNSOP decides
whether this is a problem worth solving.
I still think it's the most elegant of those proposed ;-)
I whole-heartedly agree, as Ray's idea was the basic conclusion I'd
arrived at independently.
I agree.
I believe that multiple-response and multi-qtypes solve similar but
somewhat different problems. As Wes observed during a conversation
last week, the former is for when the authoritative server believes it
knows what records you're going to want next (and even then can't
effectively signal the absence of any particular record). The latter
is driven by the client knowing just types it'll want to know about
for a given qname, and indicates explicitly what the existence of each
is.
Multi-qtypes is also far easier to implement and will be much more
useful much more quickly. It can roll out in resolvers and
authorities incrementally without depending on DNSSEC and with far
fewer security concerns. At a recent industry meeting I announcement
my intention to ask Ray to revive it and was met with fairly
widespread support from both authoritative and recursive operators.
Good!
And I think any ANAME/ALIAS record should be used in combination with
these, and of itself not define any new special handling.
Although, we should also be a bit careful not to create a new ANY type
query that will get abused for amplification, so it should really all
have source verified IP transports (DNS-COOKIES, TCP, etc)
Another issue to look at is returning any prefix special records,
such as TLSA records which do not match the QNAME, but are strongly
related to the QNAME and would benefit from being returned along.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
