Patrick: My goal is to find whether there are enough interested people to try to solve something.
My use case is very simple: skipping an on-the-wire DNS exchange can provide better security, privacy, and performance.  Can we do it safely?

Part 1: What are the possible use cases and transports?  HTTP/2 PUSH?
Part 2: When is it safe to use these records?

DKG: I think this is potentially useful in a lot of different places.  We need to be very clear about the context of the data.  Not only "is it acceptable data?", but "when might this data be usable?".  In TLS, we were just talking about DNSSEC-chain TLS extension, but there will be many other opportunities.  We have to

John Richardson:
I'm really concerned that doing DNS over DOH introduces the possibility of the internet looking different depending on which webpage you're using at a given time.  We need to talk about whether we will honor the traditional single root of DNS.

Paul Hoffman:
I think we're going to have an issue that the subject line said "Resolverless", and in DOH there is a resolver (the HTTP server).  We have two use cases here: the one that's actually "resolverless" and DOH where there is.

DKG: I think we're talking about getting DNS from places where we haven't gotten DNS in the past, e.g. HTTP/2 PUSH from a random website.  I didn't ask for those records.

Paul Hoffman: That site was not a configured DOH server.

Patrick: Right, this is about a case where you get a record from a server that is not configured.  Do we want to take a next step to give that some meaning.

John:
You talked about "where the DNS comes from".  Do you mean the server, or the zone?  In my mind, it comes from the authoritative server.

DKG:
I meant that the channel by which the application received the record may not be indicative of how reliable it is.

Tale:
You don't necessarily need a resolver in that pipeline.  If you're talking to a CDN, they can tell you information about zones that they host, with DNSSEC signatures, without ever having to ask a resolver because they already have the mapping.  It should be consistent with what you would get if you asked over the DNS protocol.

Mike Bishop:
And that's where we get into some details, because depending on client IP you're going to get different responses depending on who asks.  With Alt-Svc you can already get answers that you might never get through the DNS.  An example is coalescing: RFC 7540 says to check the DNS records before you coalesce even if they're all on the same certificate.  But some properties would like to route different users to different IP addresses but also allow coalescing.

Sara:
This is a version of split horizon.

Tale:
Consistent with the DNS but not identical.  To the extent that you are making an attestation about a name under a particular domain, that comes from the ICANN superstructure.

Patrick:
In HTTPS, WebPKI is the security system.  We allow IP MITM because that's not part of the authentication model.  If that's your security model, you may not be all that concerned about attestation.  There may be other concerns, but it's not necessarily about authentication of your peer.  Concerns like competitive issues (capturing traffic), entities being able to add themselves to the path, amplification of loss of certificate issues.  But the use case of allowing example.com to send a record for analytics.example.com is highly valuable.

:
We need to separate the idea of authoritativeness.  You might get a completely different answer this way vs port 53.  If we can make it tied to that web session, then who cares if it's different?  They're already doing geolocation steering, so this is just doing that on steroids.  You may well get something back with a DNSSEC signature.

Paul:
To amplify what you said, we may be ratholing early on the DNSSEC and authoritativeness.  Bad idea fairy: we could add an EDNS0 option indicating which aspects of this answer are universal, and can be spraypainted on a wall.

DKG:
I've got spraypaint in my bag right now.

Shane:
Do we have intuition for how this change to architecture is going to affect the network at large?  Resolvers cache, they're efficient.  Will this new architecture be more P2P and scale even better?  Or not?

Mike:
If you have H2 pushing a resource, you have ultimate caching, because the server will update its resource every 15 minutes, and push that resource to all clients.

Shane:
But you could be querying 3rd party data too.

Mike:
You could.

Subodh:
The compelling use case for us is targeting.  We do DNS-based targeting of users when they come in from a specific IP subnet, we push records for that user to visit a POP near that user, including ISP preferences for peering or transit, where the links have capacity, etc.  This would allow us to make more fine-grained decisions.  The initial DNS might be slower vs. the ISPs local caching resolver, but the subsequent requests might become way faster because they went to a POP that was closer or more optimal.

DKG;
I don't think anyone is proposing doing away with the resolvers.  No one is imagining radically reshaping the entire internet.

Shane:
I think if you're envisioning any kind of success then you do need to think about having more and more traffic shift to this model.  If you really expect this to beuseful in the generla case then you need ot imagine it taking over a significant amount of traffic:

Tale:
This has major implications for the big providers making their load and demand estimates, cache interactions, etc.  It has significant architectural implications that will tend to favor some business models over others.

Erik:
Two classes of problems, resolver is a red herring.  Do you know go through the authoritative resolvers?  Or do you treat this as the killer app for DNSSEC, i.e. verified records are good no matter how you get them?  That's one class of topics.  The other class is: how do we handle traffic routing if a client has a name and wants to get a resource?  It seems like there's a new type of camel forming here, between ECS, Alt-Svc, DOH, DNS64.  Happy eyeball variants, handling many RRs, choosing between QUIC and H2.  Lots of ways to go from a name to a connection (connection coalescing!).  Complexity there is growing, an emergent property with no single working group.

Barry Green:
The end goal: We built the DNS in an era when networks were not very stable.  If a hurricane comes through and takes an ISP offline, things should work.  If my DNS is all handled in-app over HTTP by every app, then I have an external dependency for resilience of my network.  Lets do all DNS lookup for Whatsapp in Whatsapp, but in a hurricane, what's my recovery model?

What's the end goal?  Where are we heading with this?

DKG:
I envision this as an additive set of places where I'm willing to accept DNS records.  It sounds to me like you're saying that if we make this work, then I'm going to lose my traditional DNS channel.  I don't know why we would lose it.

Sara:
On DNSSEC: one of the use cases is complete unsigned data, so I'd like to clear that up.

Patrick:
No limits in this conversation, but in a WG we could make DNSSEC mandatory, that would be in scope.

Sara:
I think Shane's right: if this works, why would you go to the other channel unless you're in a disaster mode?  If every app does this, what's left to the system resolver?

John:
What do you mean by context?  Are we talking about a webpage, or the context of the whole operating system?

Paul:
It sounds like the main use case is "faster".  This is a server pushing records to make things faster.

Patrick:
Faster and more private.

Paul:
Let's split those out.  "faster" could be handled by double-checking through the regular DNS.  That doesn't work for "private".  There might be classes of data that aren't privacy-sensitive though.  Let's not tell the users what their use cases are.

My first guess is that people want to push this for "faster", and privacy is a secondary consideration, but there are also people who want this for privacy first.

Patrick:
I think the question of context or scope is a design question.  One potential context is "https within a web browser tab", i.e. separated from other parts of the browser.  Another is "whole browser" or "whole OS", and those are very different.

As for totally removing resolver-based DNS, servers don't know all the names you will need.  They know the most obvious ones.  There will always be misses, so we'll always need resolvers.

???:
Currently, stubs are dumb with respect to DNSSEC.  Will we give applications the ability to validate DNSSEC?  As a client I would like to do it myself.  Is that possible?

Paul:
Yes.

Ray:
if we do have the situation of servers pushing records, we'll lose RPZ.  It's common for people to use DNS servers that filter DNS for botnets.

Subodh:
In addition to privacy and "fast", we also need to talk about diversity.  As we go into the DOH space, we only have one browser and one resolver right now.  Not clear how we would get more and bootstrap them.  This is one path to get bootstrapping and get more DNS entries.

Erik:
On the RPZ question, that's certainly relevant here, but it's also relevant to DOH.  For the normal use case, is there a standardized way to configure a client to use a trusted response policy server?  Otherwise, enterprise or home filtering will lose the use of DNS has a policy tool.  We need hooks so the people who control those endpoints don't lose that.

Ray:
I wouldn't like to have the RPZ choice delegated to the client.

Patrick:
We have stakeholders represented for CDNs, browsers, and website operators, but not ISPs or network operators.

Mnot:
When less information is exposed, ISPs always seem to say they don't care.  It's enterprises, schools, homes, and prisons who are going to care more than ISPs.

Patrick:
Do you think resolverless DNS is interesting in an incremental way to the use of open resolvers, or is it a different problem?  I think it's the same problem.

MNOT:
Yes, if I block port 53 for my kids, then DOH is already a problem.

:
NAT64 is also a problem, in addition to RPZ.  This is all trying to get past that, and it's going to end up breaking.  We've fixed a lot of things by bringing the fixes close and you've got to be careful here.

Barry:
With operator hat on, I think your perspective is US/EU.  The APAC operators are manipulating DNS for filtering and censorship, so if you say you're going to bypass that the operators are going to complain.  Another constituent we need to include is my mom, who is going to want to know why something doesn't work in one particular tab?  This is creating complexity per-app, per-tab that will be hard to support.

Patrick:
It's a truism that every level in an internet exchange claims that the customer calls them first.

Paul:
We started with "where might we be getting this data"?  Let's limit this to HTTP.

DKG:
I think that an interesting thought experiment would be to define the narrowest possible scope where something like this might be interesting.  If that means "within one tab", HTTPS-only, DNSSEC-signed, hopefully at some point we can find something that doesn't make too many objections, and then maybe we can walk it out.

Patrick:
With delegated short-lived certs.

Subodh:
Beyond "DNSSEC will solve all our problems", the other thing is the ORIGIN frame discussions.  If we're scoping this to HTTP-only, then we might want to apply the same considerations as ORIGIN frame, plus maybe something for wildcard handlers.  It is slightly different in terms of who can mount an attack.

Patrick:
example.com could push a DNSSEC-signed record for gmail.com.  Otherwise it would rely on WebPKI.  It could publish the IP of itself, which example.com could not produce a valid cert for, but it could forward the packets to gmail and act as a network-level MITM.  Maybe that's why we want DNSSEC.

Subodh:
Doing this at scale would be hard

Patrick:
But you can target this.

Erik:
To DKGs thought experiment: if you think of everything in a tab as stateless it might work, but once you have state it gets messier.  What if a resource in the tab alters the origin state?  Now you have a situation where an ad pixel leaks information to other tabs.

That might be something where we need to look even narrower, e.g. only to private browsing mode.  That might be a place to look at first.  This also goes to the original motivation for the ORIGIN frame: some wanted to expand the origin, and some wanted to shrink it due to corner cases with connection coalescing.  For example, some browsers will coalesce if the RRsets overlap, even if the actual IP in use isn't available in both.  Or coalescing in IPV6 when it only works in IPv4.  This is a great use case for ORIGIN frame.

Patrick:
To the extent that ORIGIN

Ben:
We need to consider a supercookie attack, where a server pushes a (DNSSEC-signed) record that's unique for each client, and then uses a tracking pixel for the domain to create a supercookie that follows them around the web.  Browser socket pools might not be designed to limit the use of a DNS record to a specific scope, so defending against this would require adding a new feature to the socket pools to prevent request coalescing from different cookie scopes on these sockets.

DKG:
Wouldn't Alt-Svc already have this problem?

MNOT:
Fingerprinting issue is tough.  Segregating sockets is controversial.  It's worth talking about.  I also know that some members of Chrome Security have fairly deeply held beliefs about the wisdom of this approach.  We should make sure to get their input.

DKG:
I wanted to observe a different between "DNSSEC-signed records for the /64" vs. Alt-Svc.  If get the signed records I can replay that to anybody else, which could generate confusion and remove the identifier.  If we're asking for DNSSEC-signed records.  That gives us the opportunity to use some kind of transparency model to try to detect bad behavior.

Patrick:
I would like to get a mailing list to focus on DKG's consideration of the minimum useful case.  If we can find a minimal case that's worth advancing then maybe we can have a BoF.

John:
Why not DOH?

Patrick:
This work is specifically out of charter for DOH.

Paul:
We're hoping to shut down the DOH working group.  I think a new mailing list is appropriate.

Patrick:
I also would like an AD to be aware of this work.