On Tue, Aug 15, 2017 at 3:05 PM, Tony Finch <d...@dotat.at> wrote:
>
>> On 15 Aug 2017, at 20:28, Paul Vixie <p...@redbarn.org> wrote:
>>
>> we can specify that AAAA be sent as additional data for QTYPE=A, and that A
>> be sent as additional data when QTYPE=AAAA.
>
> It's awkward.
>
> From the stub point of view, how does it know that the server will return
> additional address records? How does it tell the difference between no
> support, no records, or an empty cache? To what extent do the additional
> records actually help clients to avoid double queries?
>
This is a subset of draft-wkumari-dnsop-multiple-responses-05
("Returning extra answers in DNS responses."):
"Other examples where this technique may be useful include SMTP (by
including mail server addresses, SPF and DKIM records when serving
the MX record), SRV (by providing the target information in addition
to the SRV response) and TLSA (by providing any TLSA records
associated with a name). This same technique can also be used to
include both the IPv4 (A) and IPv6 (AAAA) addresses for any singular
address query."
The above document does require DNSSEC, and is clearly an
optimization, but if the auth-> recursive or recursive -> stub
includes an AAAA with an A (or the other way round), it means that
you'll have it handy.
> From the recursive server point of view, should it delay answers so it can
> fill in the additional section? What if a broken authority doesn't answer to
> AAAA queries?
>
> DNSSEC can help a bit because there would be a visible proof of nonexistence
> to disambiguate some cases.
>
>> given identical deployment curves along both the ANYA and additional-data
>> timelines, we will get identical results.
>
> ANYA has the advantage of clear signalling that the server supports it or
> not, though broken servers or middleboxes might make the negative answer
> rather slow. But we would need some kind of modelling or experimental
> evidence to see if it increases the query load by 50% (the worst case) rather
> than reducing by 50% (the goal).
multiple-responses allows servers to opportunistically include this
info. We still need to do some analysis to figure out just how much of
an improvement this generates, but it doesn't require any additional
requests. If the server (auth or recursive) knows that a client
(recursive or stub) might be able to use this into, it just shovels it
in. This leads to larger responses, but I think that we lost the
"small packets" battle long ago -- attackers who want to find big
responses for reflections can easily do so...
>
> Tony.
> --
> f.anthony.n.finch <d...@dotat.at> http://dotat.at
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
