Re: [DNSOP] re original_transport indicator

[Dave Lawrence]

Martin Thomson writes:
> I think that a better choice is message/dns.

I personally prefer this to dns-udpwireformat / dns-wireformat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] re original_transport indicator

[Martin Thomson]

On Sat, Apr 7, 2018 at 9:29 AM, Paul Vixie  wrote:
> my original design added an http header, which was seen as even worse.
> someone suggested adding to the content-type, and i went along with it even
> though there is no difference in actual type of actual content.

A header field isn't all bad.  At least from my perspective, anyway.
That said, it is true that adding to the content is a better choice.
I appreciate that this isn't a great fit in this case.

> i am generally supportive of this approach; in fact i wish i'd thought of
> it. the specifics will be different, as in:
>
> /proxy_dns?proto=tcp
> /proxy_dns?proto=udp

/request{?dns}{?proto} is the way you would write that.

> i object, as before, to "dns-udpwireformat" as a name. these are dns
> messages, which when carried by udp are raw, and when carried in tcp are
> preceded by a two-octet length indicator for framing of multiple messages
> sharing the same stream. so, the string to be registered should be
> "dns-message".

I agree with this principle, and have expressed similar concerns with
the name.  However, I just checked the media type registry [1] and I
think that a better choice is message/dns.  Just like message/http and
message/sip.

[1] https://www.iana.org/assignments/media-types/media-types.xhtml#message

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] re original_transport indicator

[Paul Vixie]

Martin Thomson wrote:

+1 to this.

And maybe there is an outcome that doesn't need this parameter.  I
probably misunderstood some of the expectations people have for the
parameter.  With the benefit of time and sleep, it's possible that I
now understand the disconnect.

My model of content-type - and by extension its parameters - is of a
description of the content.  However, it appears as though at least
some people had different uses for the parameter: for requests, it
would be an instruction/suggestion to the server to make a DNS request
using the identified transport; for responses, it would be a
description of where the DNS request came from.


my original design added an http header, which was seen as even worse. 
someone suggested adding to the content-type, and i went along with it 
even though there is no difference in actual type of actual content.



I never considered that interpretation, but - assuming that this is
what it was - and the intent was to provide a means for the client to
control how the server makes requests (and to see how they were made).
In that case, I have a possible alternative design for the use case in
the dnsop draft.

Right now, DOH doesn't really say how a DNS API Server gets its
responses.  It could be that the API server is part of a resolver, or
it could be that the DNS API Server makes a request to another
resolver.  But specific uses of the DOH protocol could come with
additional constraints that would enable the use cases in the dnsop
draft, at least as I understand them.


this all sounds good to me.


If the goal of the dnsop draft is to extend the reach of a DNS client
(note: not a DNS API client) across a network that is in some way less
hostile to HTTP than it is to DNS, then I think that it can still use
DOH.  A DNS API server could be configured to operate in a very simple
mode with no caching, just direct transposition of a request from HTTP
to a request on UDP or TCP.  A DNS client could be configured with two
DNS API clients.  Each client uses a different DNS API Server
endpoint.  Those endpoints would be specifically configured to use
only UDP or TCP.

For instance:
https://use.only/tcp{?dns} would cause the server to make a request using TCP.
https://use.only/udp{?dns} would cause the server to make a request using UDP.

At this point, this is simple DOH, but with extra contextual
information about server operation.


i am generally supportive of this approach; in fact i wish i'd thought 
of it. the specifics will be different, as in:


/proxy_dns?proto=tcp
/proxy_dns?proto=udp

but i agree that encoding the original transport in the URI is better 
than either extending the content-type or adding another http header.


---

i object, as before, to "dns-udpwireformat" as a name. these are dns 
messages, which when carried by udp are raw, and when carried in tcp are 
preceded by a two-octet length indicator for framing of multiple 
messages sharing the same stream. so, the string to be registered should 
be "dns-message".


--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] re original_transport indicator

[Martin Thomson]

+1 to this.

And maybe there is an outcome that doesn't need this parameter.  I
probably misunderstood some of the expectations people have for the
parameter.  With the benefit of time and sleep, it's possible that I
now understand the disconnect.

My model of content-type - and by extension its parameters - is of a
description of the content.  However, it appears as though at least
some people had different uses for the parameter: for requests, it
would be an instruction/suggestion to the server to make a DNS request
using the identified transport; for responses, it would be a
description of where the DNS request came from.

I never considered that interpretation, but - assuming that this is
what it was - and the intent was to provide a means for the client to
control how the server makes requests (and to see how they were made).
In that case, I have a possible alternative design for the use case in
the dnsop draft.

Right now, DOH doesn't really say how a DNS API Server gets its
responses.  It could be that the API server is part of a resolver, or
it could be that the DNS API Server makes a request to another
resolver.  But specific uses of the DOH protocol could come with
additional constraints that would enable the use cases in the dnsop
draft, at least as I understand them.

If the goal of the dnsop draft is to extend the reach of a DNS client
(note: not a DNS API client) across a network that is in some way less
hostile to HTTP than it is to DNS, then I think that it can still use
DOH.  A DNS API server could be configured to operate in a very simple
mode with no caching, just direct transposition of a request from HTTP
to a request on UDP or TCP.  A DNS client could be configured with two
DNS API clients.  Each client uses a different DNS API Server
endpoint.  Those endpoints would be specifically configured to use
only UDP or TCP.

For instance:
https://use.only/tcp{?dns} would cause the server to make a request using TCP.
https://use.only/udp{?dns} would cause the server to make a request using UDP.

At this point, this is simple DOH, but with extra contextual
information about server operation.

The concerns about the requirement for HTTPS is a relevant concern.
If there are cases where an unprotected HTTP connection carrying DNS
is expected to traverse a network without modification where DNS
encounters difficulty, maybe the dnsop draft can concentrate on that
particular aspect of this.  I don't think that the suggestion in DOH
to use HTTP/2 is a problem; DOH permits the use of any version of
HTTP.

On Fri, Apr 6, 2018 at 6:53 AM, Patrick McManus  wrote:
> Hi All,
>
> We've had quite a thread re the -05 optional parameter to the
> dns-udpwireformat registration.
>
> The parameter is defined as having no meaning for DoH, but was included to
> accommodate a use case the dnsop wg is considering. Future proofing, if you
> like.
>
> Upon consideration (and a read of 6838), I think including this in doh is
> premature because Media Type registrations can be updated by mechanisms laid
> out in RFC6838 and in this case such an update could occur without impacting
> existing DoH deployments. (i.e. it does not need to be future proofed).
>
> Therefore the definition of the parameter should accompany the work that
> makes use of it if a future standards document chooses to go down that path.
> As a bonus we avoid unused clutter if it doesn't happen. I also get the
> feeling that there isn't yet strong consensus on the anticipated use case or
> the exact form it needs to take - we should let that process work itself out
> separately before registration.
>
> I've chatted with Paul, and our recommendation is to remove the
> original_transport parameter from DoH and encourage dnsop to update the
> registration if/when a different standard needs to make use of it.
>
> thoughts?
>
> -Patrick
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] re original_transport indicator

[Patrick McManus]

Hi All,

We've had quite a thread re the -05 optional parameter to the
dns-udpwireformat registration.

The parameter is defined as having no meaning for DoH, but was included to
accommodate a use case the dnsop wg is considering. Future proofing, if you
like.

Upon consideration (and a read of 6838), I think including this in doh is
premature because Media Type registrations can be updated by mechanisms
laid out in RFC6838 and in this case such an update could occur without
impacting existing DoH deployments. (i.e. it does not need to be future
proofed).

Therefore the definition of the parameter should accompany the work that
makes use of it if a future standards document chooses to go down that
path. As a bonus we avoid unused clutter if it doesn't happen. I also get
the feeling that there isn't yet strong consensus on the anticipated use
case or the exact form it needs to take - we should let that process work
itself out separately before registration.

I've chatted with Paul, and our recommendation is to remove the
original_transport parameter from DoH and encourage dnsop to update the
registration if/when a different standard needs to make use of it.

thoughts?

-Patrick
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop