News for hackers. Stuff that matters.
Re:It is always the DNS by wruza on Thursday December 02, 2021 @11:42PM (#29426686)
DNS issues rumors/news always puzzled me (not that I ever made my honest research). Domains name system is to me basically a half-replicated/half-redirected database of {domain-name : categorized-ip-list}. Can someone please ELI5 why can’t we just GET https://<dns-ip-and-its-cert-from-dhcp>/get-ips?d=<domain>, follow 3xx, get json and that’d be it?

This question lies in the same category of questions which I’ve never managed to get answers to. Why fetching email over https is instant, but over imap it may take minutes to “sync” (or what it does there)? Why browsing is instant, but ftp was dead slow? Why all the formats (mailbox, uue, etc), when you could have a proper database with column encodings? I’m not asking anyone to answer these, cause it would be too offtopic, but these arcane issues have never left me alone.

I understand that most of it is historical, but what the heck, internet.

Re:It is always the DNS by phicoh on Friday December 03, 2021 @01:02AM (#29427095)
There are a number of issues: 1) https:/<ip-addr>/ requires PKI a certificate type that is currently not in use. It is not clear how hard it is to have those types of certificates at a large scale. 2) https is more costly (in terms of network traffic and latency) than the current UDP-based protocol used for most DNS traffic. 3) There are quite a number of DNS middleboxes. In some sense they are a curse, but they also do useful things. Going to https makes that hard or impossible. Some people will be very unhappy. 4) It is not clear if your proposal will actually be more reliable. The current web has very little caching. DNS very much depends on caching. Once you add a caching layer to those https request, you make get into the same problems as described in the article.
Re:It is always the DNS by msravi on Friday December 03, 2021 @01:07AM (#29427120)
> https is more costly (in terms of network traffic and latency) than the current UDP-based protocol

That's what I used to think. But somehow in practice, at least for me, using DoH seems to return responses much faster (DoH response takes about ~1/10th the time). Don't know why... Maybe UDP packets are being dropped in bursty traffic by the ISP?

Re:It is always the DNS by phicoh on Friday December 03, 2021 @01:27AM (#29427216)
If I remember correctly, there is a study done by Mozilla, that showed that for the long tail, DoH is faster. For the common case it is slower.

Nobody really knows why that is the case. Maybe some ISPs don't spend as much time optimizing UDP traffic compared to TCP.

Re:It is always the DNS by msravi on Friday December 03, 2021 @12:50AM (#29427025)
Somewhat related. If I use DNS-over-HTTPS with a nextdns edge server the response time is of the order of 10ms. With google 8.8.8.8 or nextdns 45.90.* it's about 130-140ms. Ever since I set up a local pihole with nextdns DoH as the upstream server, things have been very spiffy. The pihole cache also helps with sub-ms response times, especially if you set a minimum ttl of 40 mins or so.
Re:It is always the DNS by NavinF on Friday December 03, 2021 @05:39AM (#29428550)
130-140ms!? That’s very unusual. Can you reproduce that latency with UDP ping to a cloud VM or a DNS request to a cloud VM?

Maybe your router or ISP is messing with UDP or intercepting DNS and forcing you to use their DNS servers. Lots of “firewall” middleboxes do that by default. Or maybe there’s an path MTU issue that triggers retransmit on every UDP packet, but not on an established TCP connection that has learned the correct MTU.

Re:It is always the DNS by lordnacho on Friday December 03, 2021 @01:48AM (#29427332)
I have a PiHole. How do I configure DoH?
Re:It is always the DNS by msravi on Friday December 03, 2021 @01:55AM (#29427366)
Use cloudflare/nextdns DoH clients and set them to listen on some other port (like 5053/5153). Point the pihole "custom" upstream servers to 127.0.0.1#5053 and/or 127.0.0.1#5153

https://docs.pi-hole.net/guides/dns/cloudflared/

Re:It is always the DNS by xxpor on Friday December 03, 2021 @12:09AM (#29426827)
Thats essentially what dns-over-https is :)
Re:It is always the DNS by cookiengineer on Friday December 03, 2021 @03:07AM (#29427727)
Note that this is only partially true, because the RFC includes only the DNS wireformat (for TCP, with a leading bytesize). [1]

The DNS JSON API is a google only thing, because even cloudflare's DNS use different MIME types and don't support the complete API and have varying support for base64 with/without padding characters and the full 65k frame size that the spec and drafts define. EDNS request options are also mostly unsupported in practice.

Even multiple questions (A/AAAA) are partially supported and oftentimes fail dependent on which server you get as an endpoint. The URL schema is also different from server to server because everybody implements their own thing.

[1] https://www.ietf.org/rfc/rfc8484.txt