News for hackers. Stuff that matters.
Re:Open DNS resolvers, from bad to worse by TechBro8615 on Friday May 13, 2022 @06:44PM (#31373296)
> stop using third party DNS caches

What is the best way to go about this? AFAIU the root DNS servers will refuse requests for recursive resolutions. So I understand the need for a self-hosted caching resolver in the middle. But is it actually necessary? If I configure my iPhone DNS to use a root server IP [0], will it perform the recursive resolution locally? And if so, is there any downside, other than increased latency, to contacting the root servers directly?

I guess privacy and trust might be issues, when asking untrusted computers (any of the intermediate resolvers) to resolve an address for your client. You would certainly give the host of a domain more information when you contact it than you would by using a third party caching resolver as an intermediary. It’s basically a question of spraying small bits of activity to many resolvers, or all your activity to one resolver. Which is a smaller attack surface? Depends.

[0] https://www.iana.org/domains/root/servers

Re:Open DNS resolvers, from bad to worse by 1vuio0pswjnm7 on Saturday May 14, 2022 @06:55AM (#31376721)
Since the cache poisoning days, I have always run a local custom root.zone. These days I use it to redirect traffic to a forward proxy that holds DNS mappings in memory, but one can put any DNS data into that zone, e.g., the A record for example.com. This reduces the number of DNS queries to resolve example.com (assuming it is not cached) to one instead of three or more. One can prevent any DNS queries from being sent over the network if one runs an authoritative DNS server serving a custom zone with the required DNS data listening on the loopback. In any event, an authoritative DNS server that functions as a root server does accept recursive queries.

For this approach, I require bulk DNS data. However I do not need DNS data for every domain on the internet. Consequentially, it is not a large amount of data. Contemporary computers usually have more than enough primary storage space to hold it.

When I request zone files from czds.icann.org or extract DNS data from publicly available UDP scans, two methods of obtaining bulk DNS data, I am not disclosing any information about what domains I plan to look up via DNS in the future. Obtaining bulk DNS data does not reveal as much as doing piecemeal lookups, not to mention doing them contemporaneous with HTTP requests to the IP address returned by the queries. Intermediary DNS caches will see all lookup activity, as would authoritative nameservers for a domain if I query them directly. Obtaining bulk DNS data generally does not suffer from this problem.

Even more, I am not sure I understand the privacy issue around an authoritative nameserver seeing one's requests, e.g., from a stub resolver or a local cache. If I am going to visit example.com, the the operator of example.com will see the HTTP request. Why would I care if the operator of example.com's nameserver sees the DNS requests. If the concern is that network observers, not the operator of example.com, will see the contents of DNS requests made to example.com's authoritative nameservers, then that is exactly what DNSCurve prevents. Encrypt the DNS packets.

In the end, I believe bulk DNS data served from the loopback provides the greatest privacy, not to mention the best performance.

Re:Open DNS resolvers, from bad to worse by 1vuio0pswjnm7 on Saturday May 14, 2022 @11:54PM (#31385133)
"AFAIU the root DNS servers will refuse requests for recursive resolutions."

All the DNS data served by the "DNS root servers" is public and available for download via HTTP or FTP request.[FN1] As such, IMHO, there is rarely a reason to query those servers for the data they serve. I already have it.[FN1] For example, the IP address for the "a" com nameserver probably will not change in my lifetime. I am so sure of this that I have it memorised as 192.5.6.30.

A simple illustration of how to reduce DNS queries to one and reduce remote DNS queries to zero. Compile nsd as a root server using --enable-root-server. Add DNS data to a root.zone. Bind nsd to a localhost address, e.g., 127.8.8.8 and serve the zone. Configure the system resolver to query nameserver 127.8.8.8.

      mkdir /tmp/nsd-01
      cd /tmp/nsd-01
      echo . 86400 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2021101501 1800 900 604800 86400 > root.zone
      echo example.com 1 IN A 93.184.216.34 >> root.zone
      test ! -d /nonexistent||rm -rf /nonexistent
      groupadd nsd-01
      useradd nsd-01 -g nsd-01 -s /bin/false -b /nonexistent -d /nonexistent 
      chown nsd-01 /tmp/nsd-01 
      chgrp nsd-01 /tmp/nsd-01 
      printf 'server:\nipv4-edns-size: 0\nzonesdir: "/tmp/nsd-01"\nzone:\nname: "."\nzonefile: "root.zone"\n' > conf
      nsd -u nsd-01 -4 -a 127.8.8.8 -c conf -l log -P pid -f db
      cp /etc/resolv.conf resolv.conf.bak
      echo nameserver 127.8.8.8 > /etc/resolv.conf
      drill -oRD example.com 
      # cleanup
      mv resolv.conf.bak /etc/resolv.conf
      kill $(cat pid)
      rm -rf /tmp/nsd-01
      sleep 1
      userdel nsd-01
      
FN1. How to get the DNS data that the root servers provide, without using DNS:

   x=$(printf '\r\n');
   sed "s/$/$x/" << eof|openssl s_client -connect 192.0.32.9:43 -ign_eof 
   GET /domain/root.zone HTTP/1.1
   Host: www.internic.net
   User-Agent: www
   Connection: close

   eof
ftp://192.0.32.9/domain/root.zone

FN2. Except in emergencies where I have no access to locally stored root.zone DNS data. Also because I have the "a" root server IP address memorised as 198.41.0.4, I sometimes use it as a ping address.