Re: [Doh] operational considerations

[Patrick McManus <[e-mail]>]

I agree a bit. I had originally gone with incorrect (or not correct or
something like that) and Jim pushed back a tad. Its incorrect wrt the
algorithm and I think its fine to capture that if the scope is tight..

Here's another swing (with Rory's editorial changes.) that I like.

"Different DNS servers may provide different results to the same query. It
logically follows that the server which is consulted influences the end
result. Split-horizon DNS [RFC6950] is a specific example of this approach
where the answers are derived from the source of the query. If a client
selects a server that is unanticipated by this style of algorithm the
response may be not be correct."




On Mon, Nov 20, 2017 at 4:28 PM, Eliot Lear <[e-mail]> wrote:

> Hi Patrick,
>
> The answer is not just different, but inappropriate.  We need to capture
> that point because that is why remediation would be required, and why this
> is at all worth mentioning.  I propose that we take another swing at this
> text over the next few days.
>
> Eliot
>
>
>
>
> On 11/20/17 9:39 PM, Patrick McManus wrote:
>
> I've taken the (imo) best bits from Eliot, Jim, and myself.. (I've tried
> to reject 'non-default', 'proximate', and 'policy' all as things that muddy
> the issue.) what do we think of this iteration?
>
> Operational Considerations
>
> Different DNS servers may provide different results to the same query. It
> logically follows that which server is consulted influences the end result.
> Split-horizon DNS [RFC6950] is a specific example of this approach where
> the answers are derived from the source of the query. A client that queries
> a resolver which uses this style of algorithm can expect to sometimes be
> returned different answers from the responses given by resolvers which do
> not use them
>
> The HTTPS channel used by this specification establishes secure two party
> communication between the DNS API Client and the DNS API Server. Filtering
> or inspection systems that rely on unsecured transport of DNS will not
> function in a DNS over HTTPS environment.
>
> On Mon, Nov 20, 2017 at 1:05 AM, Eliot Lear <[e-mail]> wrote:
>
>> Hi Patrick,
>>
>> This is good text.  I think Jim has a point about "default resolver".
>> Also, further reduction is possible.  See below:
>>
>>
>> On 11/19/17 2:48 AM, Patrick McManus wrote:
>> > Hi Eliot - indeed this is fairly brief.. thank you. if we can keep it
>> > to this scope I'm ok - but if the section begins to grow organically
>> > we should really discuss moving to a different doc. I have a proposed
>> > minor rework of your text below which I believe to be more concise and
>> > a bit more illuminating on the root issues. Let me know what you think.
>> >
>> > Operational Considerations
>> >
>> > Different DNS servers may provide different results to the same query.
>> > It logically follows that which server is consulted influences the end
>> > result. Split-horizon DNS [RFC6950] is a specific example of this
>> > approach where the answers are derived from the (potentially natted)
>> > source of the query. A client that chooses to query a non-default
>> > resolver for a name that is using this style of algorithm may not
>> > obtain correct results.
>>
>> s/chooses to query/queries/
>>
>> s/non-default resolver/resolver that is not proximate/
>>
>> How's that?
>> >
>> > The HTTPS channel used by this specification establishes secure two
>> > party communication between the DNS API Client and the DNS API Server.
>> > Filtering or inspection systems that rely on unsecured transport of
>> > DNS will not function in a DNS over HTTPS environment.
>>
>> Eliot
>>
>>
>
>