4 ms·

for speed the ultimate solution would be DNS over HTTP/3 (DNS-over-HTTP-over-QUIC)

• dochtman 8y ago
  In that case, the HTTP part would probably just be working against you. Fortunately, people are working on DNS over QUIC: https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic/ https://datatracker.ietf.org/doc/draft-huitema-quic-dnsoquic...
  • gsich 8y ago
    Reinvention of the wheel
  • sligor 8y ago
    HTTP only adds a small size overhead due to header formatting but it won't add latency, and DNS requests are in general dominated by connection latency (outside of local network)
    • londons_explore 8y ago
      HTTP adds latency for the first request to a server, since you will have to do the 1-RTT certificate and key exchange before sending your HTTP request. For many use-cases, that penalty will be paid on every request rather than just the first request, because many DNS resolution libraries aren't designed to have persistent state, so every time the library is used, it will have to set up a new connection to the server from scratch.
      • jimktrains2 8y ago
        I think you're confusing http(s) and tls. Http(1) is a request/response protocol. Tls is the stream encryption and key negotiation protocol most heavily used. Also, tls1.3 adds 0rtt for subsequent cqlls to the same server.
      • sligor 8y ago
        you have also to do this with plain QUIC or with plain TLS adding HTTP on top of both doesn't add RTT, the point was (DNS over QUIC) vs (DNS over HTTP over QUIC)
  • Avamander 8y ago
    Are there any actual implementations being worked on?