All,
I took some random notes at the meeting. Apologies for any errors or
misstatements.
Cheers,
--
Shane
2018-07-17
Bar BoF with about 35 people.
Mark Nottingham leads the discussion.
Why not SRV for HTTP?
Some work before:
* draft-andrews-srv-http
* New URI scheme also died.
Use cases for SRV:
1. Load balancing
2. Service on alternate port
Mark Andrews: Gets around CNAME at apex issue in DNS.
Ray Bellis: Missing wildcard support, HTTPS only, more stuff.
Mark Nottingham: From the web side, we have constraints. Have to be
backwards compatible and cannot have a flag day. On the web it is
critical to maintain security boundary based on the name.
Martin Thompson: When we are talking about an unauthenticated method
(DNSSEC notwithstanding), we are uncomfortable although that is
changing.
Ray Bellis: No reason not to have a record that matches this
requirement.
Mark Nottingham: Assumption was "just use SRV", but if we mean "SRV
done right" then it is a different discussion.
Cullen Jennings: What about getting it in a way that you can use it in
every operating system?
Mark Andrews: That is dead easy. If your resolver code does not
support unknown RTYPEs then you are not compliant.
Olafur Gudmondsson: One pain point is provisioning systems, the other
is various libraries.
Steward Cheshire: Within a C API it is easy. If Javascript it is more
difficult.
Mark Nottingham: I didn't see many web people concerned about how hard
it is to set up a new record type.
Erik Nygren: The performance hit of looking it up does not justify the
work. But there is a new record type called ALTSVC is like an
extensible SRV that covers additional use cases. It negotiates what
port to use, and some other things which are actively being looked at
(such as encrypted SNI).
Mark Nottingham: This allows different name treated as the same
origin.
Not a working group document - being considered.
Tale: About performance... that has been a major obstacle. Vendors
want to get answers as quickly as possible. You could do server-side
processing, but this doesn't help across boundaries and also,
server-sides RR more difficult to get out.
Patrick McManus: Protocol version negotiation in the DNS is attractive
in many ways. But blocking is a real thing. ALTSVC fixes this by
allowing connection to be made after or while connected to the primary
service.
Ben Schwartz: two modes, totally asynchronous or blocking.
Tale: Asynchronous does not really address the same problem as SRV,
since you have to connect to the primary origin which may be what you
want to address.
Ask Hansen: Server operators can get much better control, and clients
implemented correctly can also get better behavior.
..
Paul Hoffman: What would you like now? We could do stuff.
Mark Nottingham: Now that we have use cases, what are the appropriate
paths now.
Ray Bellis: SRV is for service type to target mapping. CNAME is
supposed to be for hostname mapping, and that means every service. SRV
is service-specific.
Erik Nyren: Things that have transitional properties are very
important. Always be a need for A and records at least for some
decades.
Mark Andrews: I have always expected legacy clients.
[ discussion about deprecating technologies ]
Kazuho Oku: Key distributed via DNS is a separate record, and also
cannot handle the multiple CDN record since key cannot be shared.
Ray Bellis: ANAME shifts work to resolvers; a really bad idea.
Ben Schwartz: There are certain cases in TCP where you can risk a
SYN/ACK, one RTT.
Mark Nottingham: Interaction between web and DNS folks. I am not
expecting a lot, but we should talk together and work better and learn
the pain points and so on.
Martin Thompson: Unfiltered messages coming through. We actually get
TTL's from platforms (except Windows). This is a transition problem
and we need to look at this in terms of transition problems. Browsers
have an influence but they are not the only HTTPS clients.
Mark Andrews: SPF working group did not give themselves enough time to
switch from TXT to SPF. It requires libraries to be upgraded, along
with browsers, and whatever else needs to be upgraded. This takes 3 or
4 years.
Mark Nottingham: I am hearing that we don't know how to get from now
to the end state. We need a roadmap. We need to meet security and
performance while transitioning.
Ben Schwartz: Some people seem to think transition is infinite. I
think that it is large but probably finite. Are are there alternative
means to reach our goals that cost less?
Martin Thompson: I was not proposing that it was intractable
transition. The apex problem is a pain, and externalizes the problem
in various awful ways, and it would be better if we had a different
system. HTTP is everywhere, embedded in all sorts of things. If the
goal is to exterminate the current resolution... I don't see how every
single person could be motivated to move. I can see some of them -
certainly a browser - but there is a lot of HTTP
