upvote

points

by indolering2 hours ago |
comments
upvoteby tptacek2 hours ago|
[-]
People tried to move DNSSEC from RSA to ECC more than a decade ago. How'd that migration go? If you like, I can give you APNIC's answer.
reply
upvoteby indolering2 hours ago|
parent|
[-]
RSA is still fine given that you can't break it in a year and we aren't worried about forward secrecy.

Also, I worked for a DNS company. People stopped caring about ulta-low latency first connect times back in the 90s.

You are clearly very proud of your work devaluing DNSSEC. But pointing to lack of adoption doesn't make your arguments valid.

reply
upvoteby ekr____2 hours ago|
parent|
next
[-]
> People stopped caring about ulta-low latency first connect times back in the 90s.

They did? That's certainly going to be news to the people at Google, Mozilla, Cloudflare, etc. who put enormous amounts of effort into building 0-RTT into TLS 1.3 and QUIC.

reply
upvoteby indolering2 hours ago|
parent|
[-]
I did a large data analysis of DNS caching times across the web. Hyperscalers are the only ones who care and they fix that with insanely long DNS caching.
reply
upvoteby ekr____1 hours ago|
parent|
[-]
I'm not trying to just nitpick you here, but, the message I was responding to said "People stopped caring about ulta-low latency first connect times back in the 90s.".

It seems to me that you're saying here that (1) the hyperscalers do care but (2) it's under control. I'm not necessarily arguing with (2) but as far as the hyperscalers go: (1) they drive a lot of traffic on their own (2) in many cases they care so their users don't have to.

reply
upvoteby indolering49 minutes ago|
parent|
[-]
Sorry, the point I was trying to make is that this isn't a problem operationally.

Hyperscalers go to crazy lengths because they can measure monetary losses due to milliseconds of less view time and it's much easier when they have distributed cloud infrastructure anyway. But it's not really solving a problem for their customers. At least when I worked in DNS land ... latency micro-benchmarking was something of a joke. Like, sure, you can shave off a few tens of milliseconds, but it's super expensive. If you want to reduce latency, just up your TTL times and/or enable pre-fetching.

As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too. DoH also introduces latency, yet people aren't worried about that being a deal killer.

reply
upvoteby ekr____25 minutes ago|
parent|
[-]
> As a blocker for DNSSEC ... people made arguments about HTTPS overhead back in the day too.

They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC. So I'm not sure this is as strong an argument as you seem to think it is.

> DoH also introduces latency, yet people aren't worried about that being a deal killer.

Actually, it really depends. It can actually be faster. Here are Mozilla's numbers from when we first rolled out DoH. https://blog.mozilla.org/futurereleases/2019/04/02/dns-over-...

And here are some measurements from Hounsel et al. https://arxiv.org/abs/1907.08089

reply
upvoteby indolering16 minutes ago|
parent|
[-]
> They did, and then we spent an enormous amount of time to shave off a few round trip times in TLS 1.3 and QUIC.

But if it's worth doing for HTTP, why not for DNS?

> Actually, it really depends. It can actually be faster. Here are Mozilla's numbers from when we first rolled out DoH.

Oh fun!

reply
upvoteby ekr____13 minutes ago|
parent|
[-]
> But if it's worth doing for HTTP, why not for DNS?

I'm sorry I don't understand your question.

reply
upvoteby tptacek2 hours ago|
parent|
prev|
[-]
I don't know about "valid". "Correct", maybe? "Prescient"?
reply