On 01/11/2016 02:05 PM, Ted Hardie wrote:
>> I'm a little confused. Do you mean the justification of the COOKIE
>> requirement needs more justification, or
>> the edns-query-chain option itself needs more justification. I would hope
>> the latter is clear - it reduces the
>> need for either multiple latency bound round trips or many parallel
>> queries and their callbacks.
>>
>>
> Sorry that I wasn't clear enough here. I'm not asking for a justification
> of the COOKIE, I'm wondering how often this will work over UDP. Since the
> basic issue is that response sizes needed for validation may be large, and
> the cookie will add between 15-40 bytes, it's not clear to me what range of
> UDP payload sizes would actually allow you to use this mechanism over UDP.
Oh I see. I would expect most chains to be only 1-2 segments long, so I think
those will
fit in a UDP packet, but I have not yet done any careful calculations of that.
Obviously,
this option fits much better with edns-tcp-keepalive based (long lived)
connections, but
I think a lot of the time UDP will work fine, even with the COOKIE.
> If I understand your answer correctly, you are saying that the small number
> of bytes here doesn't change distribution of responses that fit into UDP
> significantly. ("The additional size of the COOKIE is not really a problem
> here. Those would be very few bytes compared to an abusive long chain that
> an attacker could be asking for.") If the working group believes that's
> the case, that's fine. It might be useful to include a bit of text in the
> introduction indicating that this is the expectation, but that sort of text
> in archival documents is definitely a matter of taste.
That answer was more in reply to amplification abuse, and not so much in
response to regular operation.
>
>
>>> Is there a
>>
>> reason for limiting partial answers to the top-most hierarchical
>>> responses? If so, could the document include it?
>>
>> The reason for limiting the answer from the top down is that it enables
>> the querying
>> client to extend its own chain further down, and send a new query for the
>> same data
>> with the updated Closest Trust Point further down. This method guarantees
>> that the
>> DNS client can work its way to the answer.
>>
>> If the server decides to send other parts of the chain, the client has to
>> modify its
>> query target in an attempt to get the top part of the chain it did not
>> get. And it has
>> no guarantee that the next query will give it another useful hunk of the
>> chain.
>>
>> Additionally, assuming the DNS client to DNS server connection is of high
>> latency, and
>> the DNS server itself has a low latency uplink, it might actually do the
>> DNS client a
>> disservice giving it part of the chain instead of querying to create the
>> full chain. It
>> would also be guessing as to whether the full chain is likely to fit or
>> not.
>>
>> To me, such strategies seem overly complicated, and require more code on
>> the DNS client
>> implementing handling unexpected partial answers. The top down cut-off
>> seems much simpler
>> to me. But let's ask the working group as well what they think.
>>
>>
> I think a short statement like "This strategy somewhat limits the
> opportunity to
> use cached data but results in lower code complexity for clients by
> allowing them
> to retain a common query target after a partial answer" would cover this and
> might be useful.
Are there any others that would think this paragraph would be useful to add? I
have no objection to it, but also don't really see the need to write this out.
>>> To resolve this, the client would have to be able to detect when the
>> ENDS0
>>> option is suppressed by the path, versus not offered by a Recursive
>>> Resolver. Some further text on how this is discerned would be useful;
>>> absent a method, I believe the text in 5.3 is sufficient and 6.5 not
>> useful
>>> beyond the points made in RFC 6891.
>>
>> How about removing section 6.5, but moving the one sentence in there:
>>
>> A fallback strategy similar to that described in [RFC6891] section
>> 6.2.2 SHOULD be employed to avoid persistent interference due to non-
>> clean paths.
>>
>> to the end of section 5.3? Would that resolve your issue?
>>
>> Yes, that seems to work.
Great, done in my draft. (Still waiting on Tim or Joel to tell me if I should
wait or push a new version now we are in the middle of the LC)
>
>
>>>
>>> Nits:
>>>
>>> The abstract uses the term "security aware validating Resolver". This
>> use
>>> of "security aware" appears to be the term of art used in RFC 4033, but
>>> that may not be obvious; perhaps "DNSSEC validating resolver" would be
>> more
>>> clear for an abstract?
>>
>> RFC-7719 DNS Terminology marks all of these terms as "have caused
>> confusion". I am fine with DNSSEC validating resolver", but I would like to
>> punt this question
>> to the authors of RFC-7719. I'll ping them offlist if they miss this
>> message on the dnsop list.
>>
>>
> Fair enough; I'm happy to go along with their advice, whatever it may be.
Ok, I have this item pending hearing from some more people.
>>> In section 6.3, the document says:
>>>
>>> In the event that there is greater demand for Chain Queries than can
>>> be accommodated, DNS servers may stop advertising the CHAIN option in
>>> successive DNS messages. This allows, for example, clients with
>>> other candidate servers to query to establish new sessions with
>>> different servers in expectation that those servers might still allow
>>> Chain Queries.
>>>
>>> Given that this would also apply to UDP CHAIN queries, it is not clear
>> why
>>> this is in the TCP Session Management section.
>>
>> Correct. How about renaming section 6.3 from "TCP session management" to
>> "session management" ?
>>
>>
> Sounds good.
Done on my copy as well. Thanks for the prompt reply!
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
