5 ms·

For the love of all that is holy... DNS should be UDP (or eqiv), as most building block protocols of the internet. _that doesn't mean it needs to be unencrypted

For the love of all that is holy... DNS should be UDP (or eqiv), as most building block protocols of the internet. _that doesn't mean it needs to be unencrypted_. Wasn't there DNSCurve a thing at one point that was the best of all worlds?

tialaramex 4y ago
Well, it was the Daniel Bernstein solution, so I'm sure Bernstein thought it was the best of all worlds but the rest of us not so much. There are already several other protocols you can ask/ answer DNS queries over.
tssva 4y ago
DNS has always supported UDP and TCP. Traditionally queries used UDP and transfers TCP but this wasn't a requirement of the protocol. With the advent of EDNS and large responses such as those when DNSSEC is involved TCP was increasing being used for queries even before DoT or DoH. QUIC is UDP based so by being able to handle large responses DoQ reduces the need to use TCP and brings your vision of a UDP only DNS closer to fruition.
1vuio0pswjnm7 4y ago
CurveDNS, an implementation of a dnscruve forwarder, works great. I use it on the home network. To see an example on the internet, try x=$(dq -a a ianix.com 192.5.6.30 |sed -n '/authority/{s/.* NS //;s/\..*//p;q;}') dq -a -k $x a ianix.com 104.207.143.9 dnscurve comes from the same author as the underlying encryption used in dnscurve and QUIC (and countless other solutions), and both NaCl and dnscurve predated QUIC. Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO. The author of NaCl and dnscurve was not interested in personal data mining and selling advertising services, unlike the corporations behind QUIC. Oh well. https://github.com/curvedns/curvedns https://github.com/curvedns/curvedns
- 1vuio0pswjnm7 4y ago
  Assuming downvote means the example is not working. This should work: dq -a -k uz5dns1bx64zu3pgn9nm4zfvmh2vy4hpjy7nkjz6qjcu325bg9hzcx a ianix.com 104.248.15.206 whereas using the other nameserver may not work, i.e.,: dq -a -k uz5dns2sdrnxskf5lqt46v34cdlfqb9q2lvvmpr95g3l1qh0148sf6 a ianix.com 104.207.143.9
- bogomipz 4y ago
  >"Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO." Could you or someone else say what are the privacy issues are with QUIC?
  - 1vuio0pswjnm7 4y ago
    See Section 7 of RFC 9250 that is the subject of this submission. QUIC is designed by a company that prioritises personal data collection and advertising over user privacy with respect to the company. If compromises have to be made in order to satisfy the company's interests in collecting user data and administering programmatic advertising services that include subjugating user privacy from the company, then what happens. CurveCP and dnscurve do not suffer from such commercial pressures. CurveCP and dnscurve were not designed by an online advertising services provider.
    - mritun 4y ago
      Arguments that doubts the origins and not the technical merits are very poor arguments. That’s a slippery slope that can go to any absurd extreme such as asking what’s the proof that CurveCP is free from nation-state pressure because of author’s citizenship? QUIC, despite its warts, is an open spec that anyone can review. The cryptography is based off TLS 1.3 and to prevent ossification it is fully encrypted (sans two sequence numbers). It’s really easy to read spec - really, try reading it.
      - bogomipz 4y ago
        Thanks, this was the first I had heard this mentioned and agree the passage doesn't seems grounded in opinion more than technical merit. I was curious about your comment that: >"The cryptography is based off TLS 1.3 and to prevent ossification ..." I thought that the protocol choosing the be encapsulated in UDP was the thing that was addressing protocol ossification since UDP will always be supported by OS's network stacks. Or are you referring to something else?
        4y ago
- 1vuio0pswjnm7 4y ago
  2008: NaCl, CurveCP implementation plus dnscurve design - initial release 2011: NaCl, CurveCP implementation - stable release 2012: QUIC implementation 2022: DNS over QUIC RFC
bogomipz 4y ago
DNS has always supported TCP. RFC 1034, published in 1987, made it a requirement. DNS uses TCP when replies exceed 512 bytes(barring EDNS0.) DNS also uses TCP for zone transfers. There's even a bit called the TC(truncate) bit which when set in a response informs the client to use TCP.

tialaramex 4y ago

Well, it was the Daniel Bernstein solution, so I'm sure Bernstein thought it was the best of all worlds but the rest of us not so much. There are already several other protocols you can ask/ answer DNS queries over.

tssva 4y ago

DNS has always supported UDP and TCP. Traditionally queries used UDP and transfers TCP but this wasn't a requirement of the protocol. With the advent of EDNS and large responses such as those when DNSSEC is involved TCP was increasing being used for queries even before DoT or DoH. QUIC is UDP based so by being able to handle large responses DoQ reduces the need to use TCP and brings your vision of a UDP only DNS closer to fruition.

1vuio0pswjnm7 4y ago

CurveDNS, an implementation of a dnscruve forwarder, works great. I use it on the home network. To see an example on the internet, try x=$(dq -a a ianix.com 192.5.6.30 |sed -n '/authority/{s/.* NS //;s/\..*//p;q;}') dq -a -k $x a ianix.com 104.207.143.9 dnscurve comes from the same author as the underlying encryption used in dnscurve and QUIC (and countless other solutions), and both NaCl and dnscurve predated QUIC. Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO. The author of NaCl and dnscurve was not interested in personal data mining and selling advertising services, unlike the corporations behind QUIC. Oh well. https://github.com/curvedns/curvedns https://github.com/curvedns/curvedns

1vuio0pswjnm7 4y ago
Assuming downvote means the example is not working. This should work: dq -a -k uz5dns1bx64zu3pgn9nm4zfvmh2vy4hpjy7nkjz6qjcu325bg9hzcx a ianix.com 104.248.15.206 whereas using the other nameserver may not work, i.e.,: dq -a -k uz5dns2sdrnxskf5lqt46v34cdlfqb9q2lvvmpr95g3l1qh0148sf6 a ianix.com 104.207.143.9
bogomipz 4y ago
>"Today, QUIC looks overengineered and has too many privacy issues compared to the original, IMHO." Could you or someone else say what are the privacy issues are with QUIC?
- 1vuio0pswjnm7 4y ago
  See Section 7 of RFC 9250 that is the subject of this submission. QUIC is designed by a company that prioritises personal data collection and advertising over user privacy with respect to the company. If compromises have to be made in order to satisfy the company's interests in collecting user data and administering programmatic advertising services that include subjugating user privacy from the company, then what happens. CurveCP and dnscurve do not suffer from such commercial pressures. CurveCP and dnscurve were not designed by an online advertising services provider.
  - mritun 4y ago
    Arguments that doubts the origins and not the technical merits are very poor arguments. That’s a slippery slope that can go to any absurd extreme such as asking what’s the proof that CurveCP is free from nation-state pressure because of author’s citizenship? QUIC, despite its warts, is an open spec that anyone can review. The cryptography is based off TLS 1.3 and to prevent ossification it is fully encrypted (sans two sequence numbers). It’s really easy to read spec - really, try reading it.
    - bogomipz 4y ago
      Thanks, this was the first I had heard this mentioned and agree the passage doesn't seems grounded in opinion more than technical merit. I was curious about your comment that: >"The cryptography is based off TLS 1.3 and to prevent ossification ..." I thought that the protocol choosing the be encapsulated in UDP was the thing that was addressing protocol ossification since UDP will always be supported by OS's network stacks. Or are you referring to something else?
      - 4y ago
1vuio0pswjnm7 4y ago
2008: NaCl, CurveCP implementation plus dnscurve design - initial release 2011: NaCl, CurveCP implementation - stable release 2012: QUIC implementation 2022: DNS over QUIC RFC

bogomipz 4y ago

DNS has always supported TCP. RFC 1034, published in 1987, made it a requirement. DNS uses TCP when replies exceed 512 bytes(barring EDNS0.) DNS also uses TCP for zone transfers. There's even a bit called the TC(truncate) bit which when set in a response informs the client to use TCP.