Subject: [Doh] operational considerations

From: Eliot Lear <[email-masked]>
Date: Thu, 16 Nov 2017 16:31:43 +0800

Hi everyone,

Before I get into the operational considerations part of this message, I
agree with the idea that it might be useful to have a wiki to build out
text, particularly if people find other operational considerations to
address.

What we discussed was a paragraph to talk about operational
considerations.  Here is what I propose as a starting point.  It's not
that long.  I propose not to add text around GSLB/the EDNS option.

Operational Considerations

Because DOH uses an encrypted channel that may extend beyond an
administrative boundary, several operational issues may arise.  We
discuss these below, and provide at least one possible mitigation for
each issue (there may be others).

  * When used, split-horizon DNS provides different answers based on the
    source of a query [RFC6950].  The common case of this is an
    enterprise that does not expose the existence of internal services
    to the outside world.  If a DOH server residing on the Internet may,
    therefore, provide an inconsistent answer than an internal resolver
    would.  To address the common case, a DOH client MAY contain some
    configuration, such as a list of local domains that should use UDP-
    or DPRIVE-based queries.
  * Many deployments review DNS queries and responses on the wire to
    detect for malware or other policy concerns.  Where such exposure is
    required by policy, DOH the user may wish to not configure DOH.

Eliot

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 17 Nov 2017 16:15:35 +0900

Hello Eliot,

On 2017/11/16 17:31, Eliot Lear wrote:

>      to the outside world.

>                             If a DOH server residing on the Internet may,
>      would.

This sentence doesn't make sense for me. I suggest a rewrite.

Regards,   Martin.

>              To address the common case, a DOH client MAY contain some

---

From: Jim Reid <[email-masked]>
Date: Fri, 17 Nov 2017 07:20:14 +0000

> On 17 Nov 2017, at 07:15, Martin J. Dürst <[email-masked]> wrote:
> 

So rewrite it!

---

From: Eliot Lear <[email-masked]>
Date: Fri, 17 Nov 2017 11:09:11 +0100

Hi Martin,

The sentence needs work.  See below:

> This sentence doesn't make sense for me. I suggest a rewrite.

A DOH server residing on the Internet may, therefore, respond with an
answer that is
inappropriate for internal hosts.

Better?

Eliot

---

From: Patrick McManus <[email-masked]>
Date: Sun, 19 Nov 2017 09:48:03 +0800

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.

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.

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.

---

From: Jim Reid <[email-masked]>
Date: Sun, 19 Nov 2017 12:49:36 +0000

> On 19 Nov 2017, at 01:48, Patrick McManus <[email-masked]> wrote:
> 
> 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.

I think the last sentence could be improved by deleting the reference to "non-default" and "correct results”. First, it’s not clear what a default resolver is. Or what that means. Second, the result that one of these non-default resolvers may well be correct since the correct DNS response depends on the context: ie someone on the internal net gets back the correct internal web site (or whatever) instead of the incorrect public-facing one. We could probably lose “(potentially natted)” too since that doesn’t seem to add anything useful IMO.

How about the following instead?

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 chooses to query a resolver which uses these sorts of policy-based approaches can expect to sometimes be returned different answers from the responses given by resolvers which do not use them.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Nov 2017 07:05:57 +0100

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

---

From: Patrick McManus <[email-masked]>
Date: Mon, 20 Nov 2017 15:39:21 -0500

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?

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

---

From: "Hewitt, Rory" <[email-masked]>
Date: Mon, 20 Nov 2017 21:25:55 +0000

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: (408) 650-0035

From: Patrick McManus [mailto:[email-masked]]
Sent: Monday, November 20, 2017 12:39 PM
To: Eliot Lear <[email-masked]>
Cc: [email-masked]; Patrick McManus <[email-masked]>
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?

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Patrick,

How's that?
Eliot

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Nov 2017 22:28:52 +0100

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

---

From: Patrick McManus <[email-masked]>
Date: Mon, 20 Nov 2017 16:44:10 -0500

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 <[email-masked]> wrote:

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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 20 Nov 2017 22:48:53 +0100

WFM.

Thanks,

Eliot

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

---

From: Jim Reid <[email-masked]>
Date: Mon, 20 Nov 2017 22:01:10 +0000

> On 20 Nov 2017, at 21:44, Patrick McManus <[email-masked]> wrote:
> 
> "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."

I don’t like this. Sorry. “Correct” is not the correct word to use here. I might query a split DNS server (or whatever) and get what would be the correct response for me. But if you queried that server, the answer could be wrong for you. But only you. “Algorithm” doesn’t seem right either since algorithms are not necessarily involved in determining what response a server returns. Algorithm kind of implies some sort of response rewriting and while that does happen, it’s not the only way that a server might return different answers.

Let’s simplify further. How about:

Local policy considerations and similar factors mean different DNS servers may provide different results to the same query: for instance in split DNS configurations [RFC6950]. It logically follows that the server which is queried can influence the end result. Therefore a client’s choice of resolving server may affect the responses it gets to its queries.

---

From: Jim Reid <[email-masked]>
Date: Mon, 20 Nov 2017 22:07:13 +0000

> On 20 Nov 2017, at 22:01, Jim Reid <[email-masked]> wrote:
> 

Replying to myself, eh? The above is a bit clunky. Try this instead:

Local policy considerations and similar factors mean a DNS server can sometimes provide different results to the same query: for instance in split DNS configurations [RFC6950]. It logically follows that the server which is queried can influence the end result. Therefore a client’s choice of DNS server may affect the responses it gets to its queries.