>> The question then is whether we can profile DTLS without in effect >> requiring a new implementation library. > This doesn't solve the actual problem, as compared with DNS/UDP.
For all practical purposes, DNS/DTLS/UDP is close to DNS/TLS/TCP than DNS/UDP. This is particularly true when using anycast. DNS/UDP is pretty much stateless. If we assume that an anycast address is served by a pool of servers, any server in the pool can answer the request. The responses will be identical, and the client will not see any difference. Both DNS/DTLS/UDP and DNS/TLS/TCP are different. The servers can only answer a query if they have previously completed a TLS handshake with the client. If anycast routes a query to a different server in the pool, that different server will have to repeat the TLS handshake before answering. DTLS/UDP may have a slightly lower overhead than TLS/TCP, in the sense that it will not require the TCP "ACK." But that comes at the price of less efficient error handling, and also less efficient transmission if the DNS messages happen to be larger than the MTU. If a NAT is involved, UDP will also require keep-alive traffic to "pin" the port mappings, something that is not needed nearly as much with TCP. Bottom line, DNS/DTLS/UDP does not have much of an advantage over DNS/TLS/TCP. It looks more like gratuitous complexity. -- Christian Huitema _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
