On Thu, May 02, 2019 at 10:37:30AM -0400, Phillip Hallam-Baker wrote:
> On Wed, May 1, 2019 at 2:55 PM Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
> >
>
> Web services barely make any use of HTTP beyond the end point specifier. So
> I don't really see a reason to use HTTP/3. But if you were going to use it,
> that is how I would specify it.
>
> A better outcome in my view would be to develop one (or possibly more)
> presentation layer designed expressly for Web Services. So TXT
> "version=1.0-2.0 tran=https,http3,nwsp"
Another option is to not bother with a TXT RR at all, just register a
subnamespace of /.well-known for discovery of arbitrary apps, then just
getaddrinfo() (DNS A RRset lookup), and then
GET https://${domainname}/.well-known/app-discovery/${app_urn}
using HTTP/1.1, where ${app_urn} is a URN identifying the application,
which URN would be appropriately encoded, naturally.
So, one DNS lookup and one GET -> all the discovery you need.
> People keep pointing out that layering everything over http is a bad idea.
> Well, I was one of the original authors of HTTP and I agree. HTTP/1.0 is
> arguably an OK but not great Web Services transport. None of the changes to
> HTTP since have been designed to support Web Services.
It's perfectly fine for this very particular purpose.
[The rest of this is all about DNS rather than about discovery.]
> > Now you're doing quite a few DNS lookups. If you need to convey that
> > host1 supports only version 1 and host2 only version 2, you might find
> > yourself with a transport x version cartesian product of DNS lookups to
> > do. This is bad.
>
> I am doing fewer lookups than I would if I was also doing TLSA though. One
> [...]
>
> The way I see it, we need to adopt a two stage strategy. The first step
> being to make is possible to express all the information we need to express
> in the form of widely supported DNS records. TLSA is not and will never be
> widely supported by Internet hosting providers as long as they sell DNS
> registrations at cost hoping to make their profits off selling WebPKI
> certs. Structuring DANE the way it was has not only killed deployment of
> TLSA records, it has made it very very difficult to deploy any new records.
Adding DNS RR types has a last mile problem, and it's at the UIs. So I
tend to agree with you that from here on out it's TXT all the way.
But... must we have that discussion here? Is anyone objecting to the
use of TXT RRs for discovery? At any rate, we don't even need those
(see above).
> Stage two is to provide improved ways of delivering the DNS information.
> The DNS data model is what it is and changing it would take decades at the
> least. But we can and are replacing the client-resolver protocol and can
> probably change the resolver-authoritative protocol.
Just as HTTP/2 and /3 do not change HTTP semantics -- some things are
forever, and the DNS data model is one such thing. It's not all that
wrong either. DNS has warts, but it's not fundamentally wrong, not
given the reality of IP addressing and routing. (If we could start from
scratch not just with DNS, but with TCP/IP, we might well build
something rather different, but we can't, so I'm not too inclined to
spend much time dwelling on it.)
> What I proposed with Omnibroker is that we should replace all the
> client-resolver lookups with a single request/response 'what do I need to
> know to talk service X to service Y' and back would come a set of weighted
> IP addresses and OCSP tokens.
That would be nice. Note that that isn't fundamentally at odds with the
DNS data model, though it would help to have additional metadata
currently outside the scope of DNS to bind all the relevant RRsets
together.
> > I'd much rather do something like this:
> > [...]
>
> I think that modulo the use of _discovery instead of _tcp, that approach is
> already specified in the doc but not necessarily called out.
>
> The key point is that we need to pick either one way to do this or a very
> small number of ways to do this so that DNS resolvers can choose their
> additional records wisely.
Yes, exactly. We can even do better than that (see above).
> Incidentally, one change to DNS that could give immense leverage would be
> an extension allowing multiple UDP responses to a single packet. I did this
> in Omnibroker because I can always fit requests into a single packet (since
> a DNS name is limited length) but I frequently need multiple responses.
UDP is the main source of DDoS trouble in DNS... and also a large source
of DNS' success and endurance.
I'd rather get away from UDP, not only because of DDoS issues, but also
because of confidentiality protection reasons. (Or: I wish we could
have done both, DJBDNS and DNSSEC.)
> So imagine if we had an extension to DNS so that a client can say 'I can
> handle multiple responses'. And this would allow the service to send the
> kitchen sink in return to a response. The first time a client makes a
> request of the resolver, it returns an RR that says 'I support
> multi-query'. The next time the client makes a request it goes like this
> [...]
We do have a DNS extension framework...
Nico
--
