On Wednesday, December 16, 2015 11:14:38 PM Paul Wouters wrote: > On Wed, 16 Dec 2015, Paul Vixie wrote: > > as the author of the first prototype, let me say that the client side > > proxy's only knowledge of its server side proxy is its IP address, > > whereas SSL needs a host name. i'd be happy to have all that specified by > > people who understand it, alone with client-side certs and server-side > > SSL ACL's. but i'll still likely use raw HTTP in some situations, so that > > should also be specified, even if explicitly discommended by the final > > published document. > > So raw DNS on a port other than 53 is not something that would need a > big new RFC.
i disagree, because: > And we have dprive doing DNS over TLS. ...the coffee shops i access the internet are going to block DTLS by default, without ever even knowing what it was. > > If TLS is just to break through broken or blocked port 53, we don't need > an HTTP(S) RESTful interface. Raw DNS in TLS would work fine. Same for > raw DNS on port non-53. i disagree, because the web server in question may have other duties. i don't want to burn a whole IP address for this service. so we demux on the /proxy_dns URI. > > So what is the use case for the REST interface? it's more general: could be used for server-to-server traffic, UPDATE, etc. > > And yes, I'm a little prejudiced in trying to not add port 80/443 as > another encapsulation layer underneath the internet. this is the new era of "anything goes" for DNS protocol development. as with client subnet, no matter how bad an idea is, if someone is already doing it, then the ietf documents that use. -- P. Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
