On Mon, Jul 11, 2016 at 3:33 PM, Tony Finch <d...@dotat.at> wrote:
>
> Warren Kumari <war...@kumari.net> wrote:
>>
>> Hmmm... I think that this sounds reasonable, possibly with a minor tweak.
>> Initially the EXTRA RR was never intended to be something that could
>> be queried - the EXTRA (nee ADDitional) record only existed to allow
>> copying from the master to the slave (they were instructions to the
>> nameservers, not actual RR). Now that we allow querying directly, the
>> RR type needs more discussion.
>
> One thing I vaguely wondered about is how this interacts with RFC 2181
> trustworthiness ranking.
>
> If you have a validating resolver then it can accept the additional records
> OK. That isn't safe if you aren't validating or if the zone is unsigned.
Yup -- the document says that you may only do this if you DNSSEC validate.
"4. Returning multiple answers
[snip ]
In order to include additional records in a response, these
conditions need to be met:
1. Additional records MUST only be included when the Name Server is
authoritative for the zone, and the records to be returned are
DNSSEC signed.
..."
and
"8. Use of Additional information
When receiving additional records in the additional section, a
resolver follows certain rules:
1. Additional records MUST be validated before being used."
>
> But maybe the contents of the EXTRA RRset are safe? The resolver can go and
> get the real answers asynchronously. (Probably needs a quota to avoid
> amplification.)
Yup - it could be used to instruct a (non-validating) resolver to
please go off and start fetching this list of other records... but,
seeing as everyone already validates (right?!) we don't suggest this.
> However I don't know how an authority would decide whether
> to fill in the additional data or the EXTRA RRs...
>
Hmm. It seems that we have done a poor job of wording this bit. We
meant to say that this information is always placed in the additional
section (assuming that support is signalled). The only exception to
this is if someone queries for the EXTRA record explicitly.
But, Wes, Yan and I (and anyone else interested. Tony?) will discuss
the best way to encode this in the zone file in Berlin, and also
better explain the "always stuff this in additional (because, well, it
is additional), but people can ask if they really want to..." bit
W
>> Wes and I will chat more in Berlin, but I'd like to be able to have a
>> way to insert a preference into the RR as well (if there are N extra
>> records, but only space for M, I'd like to be able to indicate which
>> are the M to include).
>> How would:
>> EXTRA pref type name
>> work for you? (pref would likely be an octet).
>
> That seems like a useful refinement :-)
>
> Tony.
> --
> f.anthony.n.finch <d...@dotat.at> http://dotat.at/ - I xn--zr8h punycode
>
>
--
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
