Re: [Doh] operational considerations

["Hewitt, Rory" <[e-mail]>]

A couple of additional tweaks (which you can, of course, ignore:

Different DNS servers may provide different results to the same query. It logically follows that which server 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. A client that queries a resolver which uses this style of algorithm can expect to sometimes be returned different answers from the responses compared with responses given by resolvers which do not use them


Thanks,

Rory

Rory Hewitt
Senior Solutions Architect
Global Services & Support
Akamai Technologies
Tel: [phone]

From: Patrick McManus [mailto:[e-mail]]
Sent: Monday, November 20, 2017 12:39 PM
To: Eliot Lear <[e-mail]>
Cc: [e-mail]; Patrick McManus <[e-mail]>
Subject: Re: [Doh] operational considerations

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