Oluf

Jeg tror jeg kommer til å vente til QUIC er implementert i socket-apiet i kernelspace på lik linje med de andre protokollene. Jeg er ikke fornøyd med ytelsen i dag. Når det gjelder DoQ lister RFC9250 ingen flere reelle argumenter. Head-of-line blocking problematikk er usannsynlig med DNS sine små og få pakker, men dette kan i såfall løses ved å benytte flere DoT-forbindelser - noe som er omtrent det samme som å benytte flere stream idr i QUIC. Fordelen med forskjellige DoT-forbindelser kontra stream idr er at man med DoT ikke trenger en mutex/lock per forbindelse for å håndtere kryptostate ved parallelisering av kommunikasjonen/streams. Videre er out-of-order støttet av DNS fra før av ved match mot query ID. Session resumption er heller ikke nytt. Så de forbedrede tingene DoQ gir er syltynt, men man kan argumentere med at det er bedre at hele internett bruker den samme protokollen og at dette i såfall bør være QUIC i stedet for TCP/TLS. Om det kommer til å skje tror jeg blir avhengig av kernel-implementeringer.

Faktisk, hvis jeg tenker meg om litt til så er jeg ganske sikker på at DoT+fastopen er raskere og mer effektivt enn dns+http3 pga dagens tcp hardware-aksjellerasjonsløsninger samt evt kernel ktls. Det kan selvfølgelig bare være midlertidig, men for en sluttbruker er tregere uansett tregere noe som feks går utover batteri.

Jeg kan ikke se at dns over http3 er noe raskere enn den eldgamle standarden TCP fastopen via DNS-TLS. Quiq har noen interessante utfordringer med brannmurhåndtering, enklere å medføre DoS samt brukersporing, da noe DNS-TLS+fastopen ikke har.