Subject: [Doh] Dedicated DoH port

From: Tomas Krizek <[email-masked]>
Date: Thu, 11 Apr 2019 19:41:42 +0200

Disclaimer: I don't adocate the use of a dedicated DoH port rather than
using port 443 for most DoH traffic. I'm simply trying to establish
reasonable defaults as a software developer and packager.

Knot Resolver will use 44353 as the default port for DoH. We've
considered using port 443 by default, but it presents many challenges.

If an admin is already running an https service on the machine, the
clash with DoH resolver can be quite problematic. In best case scenario,
the admin runs into an error (not able to bind to port 443 - quite
cryptical for someone trying to run DNS resolver who's not up to date
about DoH development). In a worse case scenario, the DoH service might
actually seem to successfully start and run alongside the unrelated
https service (e.g. when both services use systemd socket activation
with ReusePort=true - basically SO_REUSEPORT under systemd).

Those who know what they're doing will have no issues configuring their
DoH service to run on port 443. However, I think it's reasonable to use
a different, dedicated port as DoH default for packaging, documentation etc.

Since there is currently no IANA assigned DoH port, I've filed the
following user port request with IANA to establish a common default that
could be used among DNS vendors.

Service Name:         [domain-doh]
Desired Port Number:  [44353]
Description:          [DNS query-response protocol over HTTPS]
-- 
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869

---

From: Erik Nygren <[email-masked]>
Date: Thu, 11 Apr 2019 13:56:16 -0400

Would it make more sense to request something out of the well-known ports
range,
or at least outside of commonly-used ephemeral port ranges?

       Erik

On Thu, Apr 11, 2019 at 1:41 PM Tomas Krizek <[email-masked]> wrote:

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Jim Reid <[email-masked]>
Date: Thu, 11 Apr 2019 19:10:57 +0100

> On 11 Apr 2019, at 18:41, Tomas Krizek <[email-masked]> wrote:
> 

This seems a bit hasty. Perhaps there should be an I-D or RFC first? Allocating a port number from the well-known range might be a wiser choice than arbitrarily choosing 44353.

I'm not sure it's a good idea to allocate a port number just so someone can run a web server and DoH-capable DNS server on the same box. That's unlikely to be a common use case. Besides, the web server could just forward inbound DoH queries to port 53 over the loopback interface. Or something like that.

Another solution might be to update the current discovery draft to include an (optional?) port number as well as the IP address to use for DoH service.

---

From: nusenu <[email-masked]>
Date: Thu, 11 Apr 2019 18:17:00 +0000

Tomas Krizek:
> about DoH development). 

I assume knot-resolver will not enable DoH by default anyway and so
it is an explicit step by the administrator to enable DoH, right?
In that case the administrator will read your documentation on how 
to enable the DoH listener and that could say that it uses HTTPS
and HTTPS is on 443.

> Description:          [DNS query-response protocol over HTTPS]
Since DNS-over-HTTPS is specified to use HTTPS as transport
and 443 has been assigned for HTTPS, I think it would cause more confusion
to assign an additional port since it is still HTTPS.

44353 would be "default DoH port in knot-resolver"
but not "DNS-over-HTTPS" as per RFC8484.

I understand your motivation behind it but I believe
documentation should cover most of the issue and if you really want
to avoid starting if there is something else already binding on
that port you could detect that at startup and refuse to start, no?

-- 
https://twitter.com/nusenu_
https://mastodon.social/@nusenu

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 11 Apr 2019 14:21:40 -0400

Tomas, as you know, DNS-over-HTTPS is an HTTP service, identified by a
unique path.  HTTP is designed to multiplex multiple services on different
paths, sharing the same port.

Rather than choose a fixed port from the ephemeral range (which may already
be in use if you are sufficiently unlucky), I recommend using 443 as the
default for users who do not want multiplexing, and implementing FastCGI
support for users who want to operate their own HTTPS frontend.  This would
give you compatibility with essentially all common HTTPS frontend servers:
https://en.wikipedia.org/wiki/FastCGI#Web_servers_that_implement_it.

On Thu, Apr 11, 2019 at 2:11 PM Jim Reid <[email-masked]> wrote:

> This seems a bit hasty. Perhaps there should be an I-D or RFC first?
> Allocating a port number from the well-known range might be a wiser choice
> than arbitrarily choosing 44353.
>
> I'm not sure it's a good idea to allocate a port number just so someone
> can run a web server and DoH-capable DNS server on the same box. That's
> unlikely to be a common use case. Besides, the web server could just
> forward inbound DoH queries to port 53 over the loopback interface. Or
> something like that.
>
> Another solution might be to update the current discovery draft to include
> an (optional?) port number as well as the IP address to use for DoH service.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Apr 2019 13:22:58 -0500

> to assign an additional port since it is still HTTPS.

(My understanding is that the current expert for the port registry takes
a very similar stance to this.)

-Ben

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 11 Apr 2019 15:23:06 -0400

> Description:          [DNS query-response protocol over HTTPS]

i agree with other commenters that this seems like it might not a useful
allocation for a number of reasons.

For knot-resolver specifically, i'd much rather it ship with DoH
disabled by default.

In terms of integration into a modern GNU/Linux system, an interested
admin can do "systemctl enable kresd-doh.socket" to turn it on on port
443.  Or, you could imagine providing a separate OS-level
"knot-resolver-doh" package that depends on knot-resolver, supplies the
necessary module and .socket unit file, and explicitly conflicts with
the other OS-level packages that would typically listen on port 443.

Either of these solutions seems better to me (and easier for an
administrator) than establishing a distinct TCP port for DoH.

         --dkg

---

From: Petr Špaček <[email-masked]>
Date: Fri, 12 Apr 2019 12:16:31 +0200

> For knot-resolver specifically, i'd much rather it ship with DoH

Can you elaborate on the reasons, please?

Do you oppose enabling DoT by default as well?

It utterly confuses me that this very WG on one hand invented DoH
protocol because DoT is not good enough, but then WG participants claims
it should not be enabled by default.

> administrator) than establishing a distinct TCP port for DoH.

Can you elaborate? I do not understand where "easiness" of manual
configuration comes from. Here my reasoning on this topic:

Current state of DoH protocol is that it requires manual configuration
on all clients. In near future it is going to rely on hardcoded values
from browser vendor. I.e. actual hostname and port number are irrelevant
because admin (or vendor) has copy&paste then anyway.

Draft
https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-03
might be different story if WG decides to go with solutions other than
section 3, but honestly it seems that draft is not going to get
consensus any time soon.

My reading of this mailing list indicates that there is strong
opposition to any insecure means of discovery, which renders the draft
useless and we are back to copy&pasted or hardcoded values.

So, how is it easier to copy&paste or hardcode
https://doh.example.com/doh
vs.
https://doh.example.com:44353/doh
?

Having dedicated port could allow us to do everything automatically so
only copy&paste is left for admin. Default on port used by other
services requires even more manual manual configuration, which goes
against idea of having as many resolvers available as we can, with as
little effort as possible.

So, why should we make it harder for admins to make it available?

I'm eager to hear reasons.
-- 
Petr Špaček  @  CZ.NIC

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 12 Apr 2019 13:05:35 +0200 (CEST)

On Fri, 12 Apr 2019, Petr Špaček wrote:

> It utterly confuses me that this very WG on one hand invented DoH protocol 
> because DoT is not good enough, but then WG participants claims it should 
> not be enabled by default.

We're all individuals here. We have different opinions and views. You'll even 
find that some of us disagree!

-- 

  / daniel.haxx.se

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 12 Apr 2019 08:31:24 -0400

> Can you elaborate on the reasons, please?

 * one of the advantages of DoH is that it is indistinguishable from
   HTTPS traffic.  a distinct port defeats that advantage.

 * the proposed port is in the port range typically used by ephemeral
   port allocation, not something that would typically be assigned by
   IANA

 * system administrators who enable DoH services should probably prefer
   to offer other HTTPS content on the same HTTPS endpoint (e.g. at
   least a configuration page, so that when someone points their browser
   at this URL they get something human-readable).  It seems plausible
   that this requirement means that the DoH endpoint requires
   coordination/integration with any local https machniery anyway.

 * We went through this with the OpenPGP keyserver network years ago,
   when we were trying to figure out how to move HKP to HKPS.  The
   initial attempt was to put it on some special port like 11372, but
   that ended up making hkps less useful because it couldn't get through
   restrictive firewalls, so we moved to 443 instead.  Almost all hkps
   servers today use port 443, and clients have defaulted to it as well.
   This is network ossification for sure, but it's also a fact of the
   modern, messed-up thing that we call the Internet.

> Do you oppose enabling DoT by default as well?

No, because nothing else is using port 853.  I very strongly advocate
DoT being enabled by default, because none of the concerns above apply
to DoT, which was always going to be distinguishable on the wire from
traditional DNS-over-UDP or DNS-over-TCP.

Note that it's also possible to run DoT on port 443 in coordination with
an https service, if you want to avoid the ossification concerns
mentioned above
(https://datatracker.ietf.org/doc/draft-dkg-dprive-demux-dns-http/).
This is currently done on port 443 of dns.cmrg.net if you want to try
it.

> it should not be enabled by default.

I offered those mechanisms in the context of Tomas's concern that
offering it automatically on the standard port (443) would be
problematic for those services that run on the same machine as a
different https endpoint.

I already offered two different ways to make it easy for an
administrator to enable DoH on the standard port with knot-resolver,
including one that involves nothing more than installing an operating
system package, something an admin will need to do anyway.

[ trimming Petr's serious and relevant concerns about our plans for
  smooth configuration, which i agree with but think we should take up
  in a separate thread ]

> https://doh.example.com:44353/doh

it's not a question of ease -- it's a question of semantics.

If you want end users to understand what they're connecting to (with all
the various tradeoffs we've already talked about with DoH), you need to
ensure that the string you're asking them to input is semantically
meaningful.

I've voiced my displeasure elsewhere about the idea that the user needs
configure DoH with a full URL, and not just a hostname -- because most
users (and maybe even some IETFers) don't understand what a URL is, or
what the semantic difference is between entering
https://doh.example.net/doh or https://doh.example.net/bananas here.
(for that matter, most users don't even understand what a hostname is,
but due to browser same-origin policy, public advertising campaigns,
etc, they probably have at least a closer fuzzy concept of "site" than
they do of "URL").

But users *definitely* don't understand what it means to enter :44353 as
part of the URL.  If we want to argue that these choices about who to
trust with sensitive data involve meaningful user action/consent, we
need make the choices that the user handles here as simple as possible.

Encouraging the wider propagation of ":44353" as part of the broader
ecosystem is encouraging people to make the (not insignificant) trust
decision about their DNS resolver based on magic strings that they don't
understand.  Let's try to keep that to a minimum.

Furthermore, the specific action requested here was to ask IANA to
allocate a port for this -- if the port were allocated to doh, then
perhaps that changes the URL from https:// to doh:// in which case the
magic ":44353" is no longer needed.  But the distinct port has all of
the disadvantages mentioned above, and now users will have to
distinguish between doh:// URLs and https:// URLs when making their
choices about who to entrust their sensitive data to -- another thing
that users won't understand.

> So, why should we make it harder for admins to make it available?

The only "harder" part you're objecting to afaict is a single
administrative command, executed during configuration of the DNS
resolver daemon.  The tradeoff is a significant amount of complexity for
the rest of the ecosystem, and potential worse interaction with the
users.

I don't think that's a good tradeoff.

  --dkg

---

From: Jim Reid <[email-masked]>
Date: Fri, 12 Apr 2019 16:00:11 +0100

> On 12 Apr 2019, at 13:31, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

+1000

---

From: Petr Špaček <[email-masked]>
Date: Fri, 12 Apr 2019 19:46:54 +0200

> I don't think that's a good tradeoff.

Thank you for elaborate reply, I will think about it.

-- 
Petr Špaček  @  CZ.NIC

---

From: Brian Dickson <[email-masked]>
Date: Fri, 12 Apr 2019 11:45:43 -0700

Top-posting one comment, and then additional comments provided in-line.

Please read this comment carefully, as I believe it frames the issue in
ways not included at the start of this thread.

Having a DISTINCT port for DoH, does not necessarily REQUIRE that it be the
ONLY port for DoH.

Think of it as an additional port, rather than a substitute port.
Some DNS resolvers (offering DoH) might listen only on the substitute port.
Some DNS resolvers (offering DoH) might listen only on the traditional
(443) port.
Some DNS resolvers (offering DoH) might listen on both ports.
All of the above is orthogonal to whether the above resolvers listen on
853, 53, or other ports.
(A DNS resolver listening on 443 might or might not offer other services on
443.)

>    HTTPS traffic.  a distinct port defeats that advantage.

This is a bug, not a feature, from the perspective of enterprise networks
who want to avoid having DNS traffic on 443.

Having DoH clients and understand both DoH:443 and DoH:DISTINCT_PORT
facilitates the two use cases (non-enterprise and enterprise).

>    coordination/integration with any local https machniery anyway.

This is true ONLY if the end-point is a general-purpose HTTP(S) server.

I know for a fact that some resolver operators do not intend on running DNS
resolvers on machines offering other HTTP(S) content.
I know for a fact that some resolver operators do not want to us
general-purpose HTTP(S) server software to implement DoH.

And in the possible case where, for whatever reason, the same IP address is
hosting multiple services (DoH and HTTP(S)), it might
not be the case that the DoH and HTTP(S) sessions are terminated on the
same server (e.g. virtualized server environments,
or servers behind load balancers sharing an external IP.)

> This is currently done on port 443 of dns.cmrg.net if you want to try
This gets dangerously close to "bike-shed" arguments, or maybe "straw man"
logic.

Yes, it is *possible* to do <some action> <some way>.

This does not mean that it is reasonable for <some way> to be mandated,
e.g. if there are important distinctions in <some environment> which makes
<other way> much better (more scalable for instance, or more secure, or
whatever),
than <some way>.

In this case <some way> = 443, <other way> = DISTINCT_PORT.

> system package, something an admin will need to do anyway.

There are MANY more resolvers than knot, including some number of
independent
implementations (not open source). What needs to be achieved is
interoperability,
without specific dependencies on specific implementations, IMHO.

As open a *protocol* (or standard, or whatever you want to call it) is
required,
which should not be dependent about assumptions about the host OS or
resolver software.

> ensure that the string you're asking them to input is semantically

This basically gets to the UI issue vs the service offered issue.

I don't think it is either necessary or useful for the connection details
to be exposed to users in this way.

The UI can very easily display "example.com" and have this associated with
whatever the DoH operator of example.com wants.
It is the operator of "example.com", and not the user, who knows what the
full URI is (including port numbers if appropriate).

It might be the case that the operator of "example.com" provides more than
one end-point (DoH:443 and DoH:DISTINCT_PORT,
and possibly DoT:853), and either wants that exposed for user selection, or
prefers that the DoH client (e.g. browser) determine
which end-points are currently reachable, and use the first one in an
ordered list that is accessible.

In some use cases, the operator might want the user to know that port 433
is available, and for the user to select that for <reasons>.

> the rest of the ecosystem, and potential worse interaction with the
See the top of my message about why _DNS RESOLVER_ operators,
rather than generic system administrators, might prefer NOT to use 443.

This changes the balance of the trade-off on the server side.

The client side should be designed to support whatever the server operator
offers.
This might mean more complex under-the-hood configuration, or more complex
service discovery.

However, this only needs to occur when the client establishes the DNS
resolver
connection, which should only be needed when network connections change,
or when the DNS resolver connection is reset/broken/fails (regardless of
why).

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 12 Apr 2019 17:01:00 -0400

Hi Brian--

Thanks for the thoughtful followup.

> Having a DISTINCT port for DoH, does not necessarily REQUIRE that it be the

Absolutely agreed here, though i note that this discussion is in the
context of a proposed IANA registration.

I think we can all agree here that operators are always free to run
arbitrary services on any port that they like, and what the IANA
registry is managing is conventions for use.  In the discussion here
we're in the process of establishing norms about deployment, not strict
requirements.

All of my considerations written earlier were intended in that context,
and were about how i think the norms we establish here will affect the
broader ecosystem.

> On Fri, Apr 12, 2019 at 7:56 AM Daniel Kahn Gillmor <[email-masked]> wrote:

I'm sorry, but it's a feature, not a bug, for users attached to (or
routed through) networks that they neither control nor trust.

Keeping it in the enterprise lane: do you want your enterprise users to
have their connections to remote DoH servers trivially blockable by some
remote network operator that is beholden to a competitor of your
enterprise?  I certainly don't.

> general-purpose HTTP(S) server software to implement DoH.

Those operators are encouraged to run (the equivalent of):

    systemctl enable --now knot-resolver-doh.socket

and never have to think about it again. :)

For the rest of the operators who care what happens when a curious user
probes the actual endpoint in question, they might need to think about
it in a bit more detail.  And that's fine.  I'm trying to preserve both
options when it comes to deployment.

> or servers behind load balancers sharing an external IP.)

This is a distinct case, and "behind the curtain" of an organization's
internal jurisdiction -- i think we expect folks that operate machines
in complicated networks to be proficient about fiddling with port and IP
address allocation on the systems they control, so norms we establish
for the public communications network are less relevant there.

> whatever), than <some way>.
>

heh, yes, i agree.  to be clear, the demux draft above is a provocation,
designed to encourage network protocol designers to think about metadata
leakage, channel multiplexing, ossification, privacy, and traffic
analysis.  It's not at all a "mandate".  It's a demonstration of the
lengths that people will go to when the network ossifies around them
based on designed-in leakage.

> independent implementations (not open source). What needs to be
> achieved is interoperability, without specific dependencies on
> specific implementations, IMHO.
>
> required, which should not be dependent about assumptions about the
> host OS or resolver software.

Agreed.  That's why i think we shouldn't deviate from the standard port
443.

> The UI can very easily display "example.com" and have this associated
> with whatever the DoH operator of example.com wants.  It is the
> operator of "example.com", and not the user, who knows what the full
> URI is (including port numbers if appropriate).

you say "very easily" and i hear "simple matter of UX design" (by
analogy with "SMOP").  Perhaps you have UX design background and
experience, but the majority of the people i meet at the IETF (including
myself) definitely do not, and have given very little thought to the
difficulties of designing interoperable, meaningful, secure user
experience for the protocols that we use.  The example you then give
describes a range of things that the protocol needs to expose to the
user without giving any clear directive how to do it.

I just don't think it's that simple, unless we accept a configuration
option that is a pre-populated list with only the names of a handful of
operators; but that further entrenches the consolidation concerns i
believe we both share.

The norms we establish about DoH service discoverability and
representation (hopefully in a different thread) will have a real impact
on our ability to offer users meaningful choice in their decisions about
who to trust with their sensitive metadata.

> See the top of my message about why _DNS RESOLVER_ operators, rather
> than generic system administrators, might prefer NOT to use 443.

By all means, they should offer their services on whatever ports they
want.  My dns.cmrg.net service offers DoT on several non-standard ports
as well (53053 and 443 in addition to the standard 853).  But i wouldn't
want to register those with IANA.

   --dkg

---

From: Brian Dickson <[email-masked]>
Date: Fri, 12 Apr 2019 14:37:35 -0700

> Thanks for the thoughtful followup.

You're welcome.
(I prefer to think first and only then stick my foot in my mouth. ;-) )

> enterprise?  I certainly don't.

Actually, I want to have my cake and eat it too.

In this case, the enterprise use case would probably best be met by:
- an enterprise end-point running on a non-443 port (possibly DoT, or
DISTINCT_PORT)
- which forwards queries to an external DoH provider (on 443)

So, the internal user would not have DIRECT access to the external DoH
server,
but WOULD have indirect access.

The enterprise forwarder might do other things (regular DNS stuff, like
RPZ, malware detection),
but might otherwise be configured/operated so as to not interfere with
privacy. Having such a
well-defined, standardized DISTINCT_PORT allows an enterprise to easily set
that up, without
having the problems of 443 outbound DNS leakage.

It's something that clearly needs to be figured out between all the parties
involved, including
the browser software folks, and probably needs to fail safe, if the host is
inside an enterprise,
the user is not a privileged (admin) user, and no new "opt-in" type extra
configurations for these
new enhancements have been done (new includes vanilla DoH, IMHO).

> user without giving any clear directive how to do it.

I see the "under-the-hood" elements and the UX elements as being
loosely related but mostly orthogonal.

If there is a standardized "publishing" spec for each DNS provider,
perhaps as one or more RR types in DNS, in some well-known place
(like an underscore namespace, standardized via the IETF),
that would allow the mapping of DNS provider's base name to whatever
the DNS provider wanted to offer.

The UX piece is something separate, and as long as the semantics are
preserved,
implementations should be free to do whatever they want. At that point,
the presentation stuff is truly orthogonal to the publishing/discovery.

Also, browser vendors have lots of developers, with hopefully some UX
skills and experience.

> want to register those with IANA.
Maybe, but as long as someone does want to register, we should standardize
on that,
and publish that, as an OPTIONAL port choice to use.

A given DNS resolver operator would then have lots of good options,
basically
as check-boxes: UDP/53, TCP/53, TLS/853, HTTPS/443, HTTPS/NEWPORT,
HTTPS/numeric-custom-port-number

Brian

---

From: Tomas Krizek <[email-masked]>
Date: Thu, 25 Apr 2019 09:07:47 +0200

> Description:          [DNS query-response protocol over HTTPS]

To follow up on this information, this request was declined by IANA.

Overall, my impression from this community, as well as the RFC 8484 and
IANA, is there is a strong preference for port 443 for DoH.

I understand the reasons for it and I'll keep investigating the
packaging options for Knot Resolver to use this port 443 on our users list.