Re: [Doh] operational considerations

[Eliot Lear <[e-mail]>]

WFM.

Thanks,

Eliot


On 11/20/17 10:44 PM, Patrick McManus wrote:
> 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]
> <mailto:[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]
>>     <mailto:[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
>>
>>
>
>