[{"author": "George Michaelson", "text": "in the room is quiet (as in low volume, I had to turn my client to max)<br/>", "time": "2022-03-23T09:01:03Z"}, {"author": "George Michaelson", "text": "maybe AV guys can up volume a bit in the venue?<br/>", "time": "2022-03-23T09:01:12Z"}, {"author": "Jonathan Reed", "text": "I can confirm it's 5am in Boston :-). (Hi Dave!)<br/>", "time": "2022-03-23T09:02:59Z"}, {"author": "Dave Plonka", "text": "Hola!<br/>", "time": "2022-03-23T09:03:10Z"}, {"author": "Jen Linkova", "text": "Hello, I'll be a jabber scribe - if you don't like to use Meetecho audio and prefer me to relay a question/comment, pls prepend your statement with \"RELAY\" or \"MIC\"<br/>", "time": "2022-03-23T09:04:50Z"}, {"author": "Dave Plonka", "text": "Tnx, Jen<br/>", "time": "2022-03-23T09:05:44Z"}, {"author": "George Michaelson", "text": "this side channel is only because we chose not to do NSEC3.<br/>", "time": "2022-03-23T09:10:30Z"}, {"author": "George Michaelson", "text": "well that, and the a.b.c.d single hex digit space is not too much to walk, in a descent<br/>", "time": "2022-03-23T09:11:23Z"}, {"author": "Jen Linkova", "text": "I suspect the majority of addresses do not have reverse delegations...<br/>", "time": "2022-03-23T09:14:13Z"}, {"author": "George Michaelson", "text": "Its a testable proposition, given that each PTR delegation demands a domain: object in whois, and the parent zones are published via FTP<br/>", "time": "2022-03-23T09:15:00Z"}, {"author": "Geoff Huston", "text": "lesson 1 - DONT USE ipv6.arpa -OR- use a synthetic server that responds to any address and never responds with NXDOMAIN!<br/>", "time": "2022-03-23T09:15:44Z"}, {"author": "George Michaelson", "text": "since most delegates have a single /32, its ~~ number of address holders<br/>", "time": "2022-03-23T09:15:50Z"}, {"author": "Shumon Huque", "text": "RFC 8020 semantics were a clarification, not a new enhancement to the spec to aid caching. With DNSSEC, the NSEC/NSEC3 records in an NXDOMAIN response cryptographically prove that nothing below the name exists.<br/>", "time": "2022-03-23T09:26:08Z"}, {"author": "Jonathan Morton", "text": "which, to be fair, is a valid condition - for *forward* resolving<br/>", "time": "2022-03-23T09:30:18Z"}, {"author": "Jonathan Morton", "text": "the points here are about *reverse* resolution specifically<br/>", "time": "2022-03-23T09:30:50Z"}, {"author": "Christian Veenman", "text": "We cannot hear you<br/>", "time": "2022-03-23T09:36:58Z"}, {"author": "George Michaelson", "text": "I think his iBuds are losing charge or BT binding<br/>", "time": "2022-03-23T09:37:50Z"}, {"author": "George Michaelson", "text": "echo cancelling outcome maybe?<br/>", "time": "2022-03-23T09:38:40Z"}, {"author": "George Michaelson", "text": "Not to over-do it, why would you do DOH3 in preference to DOQ? especially if the HTTP3 header cost is higher?<br/>", "time": "2022-03-23T09:55:56Z"}, {"author": "George Michaelson", "text": "I must be missing something like \"its easier to deploy\"<br/>", "time": "2022-03-23T09:56:11Z"}, {"author": "George Michaelson", "text": "Whats the current ratio of high speed internet GEO to LEO? In Australia, anyone on the (old) national sat network is hoping to move over to LEO as soon as a ground station opens near to them. 50ms delay!<br/>", "time": "2022-03-23T09:58:13Z"}, {"author": "Erik Nygren", "text": "One use-case for DoH3 vs DoQ is if you want HTTP semantics for other reasons (eg, embedding configuration in URI template, auth tokens, etc).<br/>", "time": "2022-03-23T09:58:26Z"}, {"author": "Sara Dickinson", "text": "For the same reason browsers do DoH instead of DoT (stub to recursive) - they see advantages because they can leverage HTTP caching/proxing behaviour<br/>", "time": "2022-03-23T09:58:40Z"}, {"author": "George Michaelson", "text": "so its the bundle effect. \"if you're using it already, for other things, it makes sense to carry DNS over it\"<br/>", "time": "2022-03-23T09:58:47Z"}, {"author": "Erik Nygren", "text": "(but for recursive-to-authoritative DoQ seems like the obvious solution)<br/>", "time": "2022-03-23T09:58:55Z"}, {"author": "Matthias W\u00e4hlisch", "text": "@Mike on slide you say that you found 264 verified resolvers which support of all targeted DNS protocols. two questions: (1) how did you do the verification? (2) any more details that you can share about these hosts (same prefix, AS etc.?)?<br/>", "time": "2022-03-23T10:01:17Z"}, {"author": "Erik Nygren", "text": "@Mike: did you also study how multiple requests over a long-lived connection compared in the face of&nbsp;&nbsp;packet loss?&nbsp;&nbsp;That seems like a potentially common real-world scenario where DoQ might have a big advantage due to lack of HOL blocking.<br/>", "time": "2022-03-23T10:03:14Z"}, {"author": "George Michaelson", "text": "wow nginx looks terrible on this. its good to have free but I like Free to be good!<br/>", "time": "2022-03-23T10:03:39Z"}, {"author": "George Michaelson", "text": "also I dont understand why caddy isn't on the test set. Is it totally OBE?<br/>", "time": "2022-03-23T10:04:39Z"}, {"author": "George Michaelson", "text": "Sats being delay bound its a strict queue, once you manage loss (L2 FEC?) its TDM like. you have a contract for use of the BW.<br/>", "time": "2022-03-23T10:05:59Z"}, {"author": "Mike Kosek", "text": "@Erik: we are currently working on measurements with long-lived connections, so not yet. but the interaction with packet loss is an interesting thought.<br/>", "time": "2022-03-23T10:06:21Z"}, {"author": "George Michaelson", "text": "he really does need to qualify SAT == GEO SAT<br/>", "time": "2022-03-23T10:08:42Z"}, {"author": "George Michaelson", "text": "we have a vibrant market in low delay LEO SAT now, with significant b/w<br/>", "time": "2022-03-23T10:08:56Z"}, {"author": "Erik Nygren", "text": "@Mike:&nbsp;&nbsp;My guess would be that the p95 response times for parallel lookups would especially survive loss better in DoQ than DoH2/DoT. (I agree with Lorenzo that comparing total bytes and packets sent would also be interesting)<br/>", "time": "2022-03-23T10:09:40Z"}, {"author": "Mike Kosek", "text": "@Matthias: yes, sure thing. (1) those 264 are a subset of the 1217 DoQ resolvers, and we identified those 264 by optimistically sending DoTCP, DoUDP, DoT, DoH queries. (2) as for geographical distribution, those 264 are located in Asia with 123 (46.59%), EU with 83 (31.44%), NA with 51 (19.32%), OC (5 resolvers, 1.89%) and AF (2 resolvers, 0.76%). We have AS-distribution on the 1217 resolvers in the paper, but I do not have stats for the 264 at hand right now<br/>", "time": "2022-03-23T10:10:59Z"}, {"author": "Matthias W\u00e4hlisch", "text": "thanks @Mike!<br/>", "time": "2022-03-23T10:11:19Z"}, {"author": "John Border", "text": "GEO satellite links are usually very asymmetric.&nbsp;&nbsp;So, different strategies might work better depending on the direction.<br/>", "time": "2022-03-23T10:13:49Z"}, {"author": "Mike Kosek", "text": "@Erik: makes sense. also considering the initial RTO of QUIC which does diverge from TCP<br/>", "time": "2022-03-23T10:17:24Z"}, {"author": "Lorenzo Colitti", "text": "@George: the reason for DoH is that I think notable implementations such as dns.google or cloudflare don't support DoQ (or not yet)<br/>", "time": "2022-03-23T10:17:45Z"}, {"author": "Lorenzo Colitti", "text": "it does seem like DoQ is better for DNS, I hadn't considered the HOL blocking issue that Erik pointed out<br/>", "time": "2022-03-23T10:18:36Z"}, {"author": "Lorenzo Colitti", "text": "I think having data showing that DoQ performs better than DoH would help convince the teams running those services to implement DoQ<br/>", "time": "2022-03-23T10:19:20Z"}, {"author": "Lorenzo Colitti", "text": "(and teams building clients, like ourselves, as well)<br/>", "time": "2022-03-23T10:19:37Z"}, {"author": "Mike Kosek", "text": "@Lorenzo: for DoH3, do you signal H3 via alt-svc on DoH connections?<br/>", "time": "2022-03-23T10:20:53Z"}, {"author": "Sara Dickinson", "text": "The HOL issue was a major driver in developing the DoQ spec - Adguard run a DoQ based service and anecdotally report equal or better performance for DoQ vs DoT/H particularly in mobile networks which they attribute to better handling of packet loss<br/>", "time": "2022-03-23T10:20:56Z"}, {"author": "George Michaelson", "text": "I think Sara and others pointed out DOH3 has advantages in other ways. Its not a shootout, there might be a range of issues to balance out<br/>", "time": "2022-03-23T10:20:59Z"}, {"author": "Erik Nygren", "text": "I think there may also be very different practical answers for client-to-recursive vs stub-to-recursive than for recursive-to-authoritative.&nbsp;&nbsp;For the first two, DoH2/DoH3 may both be needed (and perhaps DoT/DoQ as well) but for the third I've wonder why we need anything other than DoQ.<br/>", "time": "2022-03-23T10:24:40Z"}, {"author": "Sara Dickinson", "text": "Of the implementors I've spoken too they seem keen to jump straight to DoQ for recursive/auth (but performance data would really help cement that decision)<br/>", "time": "2022-03-23T10:25:48Z"}, {"author": "Sara Dickinson", "text": "For stub/recursive I can see a bit of evolution still happening involving all the protocols for the foreseeable but I can imagine a mix of DoHTTP/3 and DoQ longer term<br/>", "time": "2022-03-23T10:27:13Z"}, {"author": "Will Hawkins", "text": "Thank you -- really fascinating!<br/>", "time": "2022-03-23T10:32:59Z"}, {"author": "Ties de Kock", "text": "/9, 0.2%?<br/>", "time": "2022-03-23T10:34:40Z"}, {"author": "Matthias W\u00e4hlisch", "text": "@Ties, yes, my bad, roughly 1/512.<br/>", "time": "2022-03-23T10:42:21Z"}, {"author": "Mike Kosek", "text": "thanks all, bb<br/>", "time": "2022-03-23T11:02:51Z"}, {"author": "Jerome Mao", "text": "thanks all!<br/>", "time": "2022-03-23T11:03:00Z"}, {"author": "Mirja K\u00fchlewind", "text": "Thanks all speakers!<br/>", "time": "2022-03-23T11:03:02Z"}]