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 AAAA 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 out there. Patrick McManus: Service versus host in the industry is not a very important distinction. Load balancing solved in other ways. Apex issue may be an issue. Ray Bellis: Add an experimental type to BIND and just try it out. Kazuho Oku: I would prefer defining it in a way that provides consistency to convert to the same set of A or CNAME records. Ask Hansen: More like EDNS client subnet than MX records. Small percentage of servers that need it. Mark Nottingham: No specific actions. Where to discuss? [ everyone wants to discuss somewhere ] Action: Adam Roach will set up a mailing list.