On Feb 14, 2018, at 6:06 PM, Jan Komissar (jkomissa) <jkomi...@cisco.com> wrote:
> Currently, there are only plans for DPN, and that would force every 
> connection to be TLS. However, if a future protocol “Z-over-DSO” does not 
> require TLS, it is possible that a client would create a TCP connection for Z 
> and later would want to send DPN operation to the same server. Note that the 
> DSO client may represent a single computer, while the Z and DPN requests 
> represent applications on that computer that implicitly depend on those two 
> protocols. I guess a new connection could be created, but it would be better 
> if not necessary.

Hm, is that really true?   What is the scenario that you envision here?  Like, 
when would this actually happen?   What's the client that's making the 
connection?   How is it that it is the same client that's doing DPN?   If it is 
configured to support TLS, why isn't it defaulting to that?

>  The interop issue is related to section 4.1 that says that any session based 
> protocol is suitable for DSO. If you make a server that only supports DSO 
> over TCP and I make a client that only supports DSO over QUIC, they are both 
> compliant with the draft, but they cannot communicate with each other. To 
> avoid this, I suggest that this draft only supports TLS (and possibly TCP), 
> and supporting DSO on any other underlying protocol would require a new 
> document.

I think I've heard other suggestions that we should enumerate which protocols 
are supported explicitly, but I don't think there's a requirement to support 
DSO over anything.   We're just describing a new DNS message type that can be 
used with any connection-oriented protocol.

You didn't answer my third question:

> Also, do you think that DNS-over-TCP should be formally deprecated?   If so, 
> perhaps that's the right way to address this.   If not, can you say why DSO 
> is special and requires TLS, when DNS-over-TCP does not?

Is is that you want to make DSO-over-TLS MTI and DSO-over-TCP optional?

DNSOP mailing list

Reply via email to