Re: [Doh] operational considerations

[Eliot Lear <[e-mail]>]

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
>
>