Nyere Android-versjoner har i det stille fått støtte for DNS over HTTP/3

[Harald Brombach (digi.no)]

Nyere Android-versjoner har i det stille fått støtte for DNS over HTTP/3

[bmork]

Dette er bare dustete. DoQ er standardisert ( https://datatracker.ietf.org/doc/html/rfc9250 ) og gir alle fordelene med QUIC uten noen av ulempene HTTP medfører. Så hvorfor gjør de da noe slikt? Jeg har noen forslag til svar på det spørsmålet, men ingen som egner seg på trykk...

[geirha]

Så frem Google er med på dette her... blir jeg skeptisk.

[Memento scientiam (takk for meg)]

bmork skrev (9 timer siden):

Dette er bare dustete. DoQ er standardisert ( https://datatracker.ietf.org/doc/html/rfc9250 ) og gir alle fordelene med QUIC uten noen av ulempene HTTP medfører. Så hvorfor gjør de da noe slikt? Jeg har noen forslag til svar på det spørsmålet, men ingen som egner seg på trykk...

Kjør på. 

[jyggo]

bmork skrev (16 timer siden):

Dette er bare dustete. DoQ er standardisert ( https://datatracker.ietf.org/doc/html/rfc9250 ) og gir alle fordelene med QUIC uten noen av ulempene HTTP medfører. Så hvorfor gjør de da noe slikt? Jeg har noen forslag til svar på det spørsmålet, men ingen som egner seg på trykk...

Så du har ikke egentlig noen forslag? Eller har du kun useriøse forslag?

Endret 23. juli 2022 av jyggo

[Oluf]

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.

[Oluf]

5 minutes ago, Oluf said:

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.

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.

[bmork]

4 hours ago, jyggo said:

Så du har ikke egentlig noen forslag? Eller har du kun useriøse forslag?

Tja.  Grunnene er nok de samme som for DoH, der DoT åpenbart er et mye bedre alternativ hvis du ønsker DNS over en TCP-basert TLS-sesjon.

Vil anbefale å lese https://blog.apnic.net/2019/11/04/dns-wars/

Og ta deg gjerne tid til å se foredraget.  Du trenger ikke være 100% enig med Paul Vixie for å ha utbytte av det. God underholdning er det uansett

Endret 23. juli 2022 av bmork

[bmork]

4 hours ago, Oluf said:

Quiq har noen interessante utfordringer med brannmurhåndtering,

IMHO bør du uansett holde brannmurer  langt langt vekk fra DNS. De vil bare bidra til å forsterke effekten av angrep.

 

[bmork]

4 hours ago, Oluf said:

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.

DNS over HTTP/3 er som sagt bare dustete.

Du bør heller se på DoT vs DoQ. DNS over QUIC er designet for lav latency fra grunnen av, ref https://datatracker.ietf.org/doc/html/rfc9250#section-3.2  Dette omfatter mer enn bare 0-RTT, som er det fastopen gir deg.

Jeg spår at de TCP-baserte DNS-løsningene forsvinner på sikt. slik at vi sitter igjen med klassisk DNS over UDP for legacy klienter og andre som sliter med TLS, og DNS over QUIC for alle andre. DoH(/3) blir bare en historisk fotnote vi kan le av.  Kan ihvertfall håpe 🙂

 

 

[jyggo]

bmork skrev (20 timer siden):

Tja.  Grunnene er nok de samme som for DoH, der DoT åpenbart er et mye bedre alternativ hvis du ønsker DNS over en TCP-basert TLS-sesjon.

Vil anbefale å lese https://blog.apnic.net/2019/11/04/dns-wars/

Og ta deg gjerne tid til å se foredraget.  Du trenger ikke være 100% enig med Paul Vixie for å ha utbytte av det. God underholdning er det uansett

Takk, will do

[Oluf]

21 hours ago, bmork said:

DNS over HTTP/3 er som sagt bare dustete.

Du bør heller se på DoT vs DoQ. DNS over QUIC er designet for lav latency fra grunnen av, ref https://datatracker.ietf.org/doc/html/rfc9250#section-3.2  Dette omfatter mer enn bare 0-RTT, som er det fastopen gir deg.

Jeg spår at de TCP-baserte DNS-løsningene forsvinner på sikt. slik at vi sitter igjen med klassisk DNS over UDP for legacy klienter og andre som sliter med TLS, og DNS over QUIC for alle andre. DoH(/3) blir bare en historisk fotnote vi kan le av.  Kan ihvertfall håpe 🙂

 

 

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. 

 

 

 

 

 

[bmork]

35 minutes ago, Oluf said:

Head-of-line blocking problematikk er usannsynlig med DNS sine små og få pakker,

Nja, er nå ikke helt overbevist om det.  Antar vi primært snakker om forbindelsen mellom klient og cachende resolver, ettersom det stort sett bare er der TLS gir noen mening.  Da har du en salig blanding av queries som kan besvares fra cache, queries som krever mange oppslag ut i verden og queries som feiler med timeout ette flerfoldige sekunder. Kombinert med en aggressiv klient som foretrekker å spørre en gang for mye enn å måtte vente på svar.  Kjører du alt dette i én strøm så kan det godt være at noen av queriene som kunne blitt besvart fra cachen ender opp med å vente bak tusenvis av kopier av den ene queryen som konsekvent feiler/timer ut.

41 minutes ago, Oluf said:

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.

Ja, sett fra klienten så er det nok ett fett.  Men det blir ikke det samme for serveren.  Veldig mange uavhengige TLS/TCP-sesjoner per klient vil være problematisk.  Serveren må sette en nokså lav grense der for å garantere nok kapasitet og beskytte seg mot DoS.  En dullion QUIC-streams tilhørende samme sesjon er helt uproblematisk i forhold.  Det er fremdeles bare én TLS-sesjon.

Men jeg ser ikke bort fra at DoQ først tar av når TCP begynner å dø ut.  Noe som forhåpentligvis tar litt tid.

[Oluf]

5 hours ago, bmork said:

>   Veldig mange uavhengige TLS/TCP-sesjoner per klient vil være problematisk. 

Hvorfor det ? 

På TLS-nivå gjør session reuse det trivielt å ha tusenvis av forbindelser mot samme klient.

Hvis det er antall åpne sockets du tenker er problemet så blir det ikke noe forskjell på dette og antall åpne streams med QUIC.

Man må uansett lagre state, sekvens idr, socketbuffer per stream osv hvis man snakker om en fullverdig QUIC-implementasjon.

 

 

 

Endret 24. juli 2022 av Oluf

[bmork]

16 hours ago, Oluf said:

På TLS-nivå gjør session reuse det trivielt å ha tusenvis av forbindelser mot samme klient.

Hmm, det har du rett i.

I praksis er det nok mindre forskjeller på DoT og DoQ enn jeg ser for meg . Så lenge man bare konfigurerer TLS og TCP fornuftig.  QUIC har færre alternativer og dermed færre muligheter for å tråkke feil. Men det spiller jo ingen rolle så lenge man bare gjør alt riktig uansett 🙂