Reverse DNS queries may reveal too much, computer scientists argue Computer scientists at the University of Twente in the Netherlands have found the interplay between the internet and local networks can be analyzed to reveal private data and facilitate tracking. In a study titled, "Saving Brian’s Privacy: the Perils of Privacy Exposure through Reverse DNS," Olivier van der Toorn, Raffaele …
> ..the opportunity to rob an associated location when it's unoccupied.
Yes, I go out. Yes, come on over. My 98 pound (45kg) dog needs the exercise/snack.
Altho you may have a hard time knowing. My public DCHP has not changed since 2018.
> ..to rob ...when it's unoccupied.
(Technically a sneak-in without assault is not robbery, but this is not the Law Site either.)
That's not failing to follow the spec. It's expected and shouldn't surprise anyone. Hosts lose connection frequently without having sufficient notice to send that message. If I disconnect my computer's cable, do I go through the network configuration to release my address? When I walk out of WiFi range with my phone with me, does it know that it's going to a new place, rather than back into range, so it can use the waning signal to release its address? If I have a power failure, have I included a bigger backup battery so that, while it's syncing disks, it can also clean up its network assuming the network device wasn't also in the power failure? In personal usage, the occasions where it's feasible to release the address are dwarfed by those where it's not.
Yes, institutions sitting on too many IPv4 addresses and assigning public ones to devices that don't need that just because they can.... plus people assigning their names to devices - still, all the "brian" are the same people?
"all the "brian" are the same people?"
The article does mention there are multiple Brians and they did not specify which, if any, were the same one for privacy reasons. I was more struck by the "new" Galaxy owning Brian and their speculation he had just bought it based on it's first appearance. That was only one possible reason. Another equally, possibly better reason, is the the Galaxy toting Brian had just returned from some time away or was a new employee. Not all employees start with the academic year. Any of the non-academic staff might start or leave any time.
That is possible, but the current theories are:
1. Brian bought an electronic device after a holiday where buying things is common and stores frequently run sales.
2. A new person was hired to start immediately after a holiday and not in line with the schedule normally used.
Both are possible, but one seems more likely to me. Of course, there are other possibilities, such as Brian had a celebration at which he was given a phone as a gift, Brian received a loner device after breaking his previous one, and someone overheard the researchers and set up a plot to confuse them.
> Not all employees start with the academic year. Any of the non-academic staff might start or leave any time.
Even academic staff. I--- and C--- had sudden brain tumors. B---- made a disturbingly improper suggestion to a student. J--- broke a leg bad. W---- died. All left abruptly. Temps ("Brian? You free?") were brought in to finish the semesters.
* emphasis added
> still, all the "brian" are the same people?
You don't need to follow him. You don't need to follow anybody! You've got to think for yourselves. You're all individuals! You're all different! You've all got to work it out for yourselves!
This only affects DNS that is integrated with DHCP. Who does that? Why would you? Anything that should be accessible by an internet host name should not be on a DHCP address.
Sounds more like they discovered a known-poor network design and needed to come up with some 'research' to convince their IT department to correct it.
In the majority of residential connections, the PTR will just be ip-add-re-ss.dynamic.provider.domain or ss.re.add.ip.customer.provider.domain - giving away absolutely nothing more than the fact that it is a dynamic address. The majority of business connections will have something sensible in there, but it won't be changing.
This post has been deleted by its author
If you know the hostname you want to track then it is much easier to use DNS.
myprecious.somedomain will always show the IP address of myprecious whenever it still has a valid lease.
So this is as much a DNS as an rDNS risk.
rDNS is just one way to find valid hostnames, but any (brute force) DNS query of a domain would give a more complete overview.
And if rDNS is considered a greater risk than DNS then disabling the creation of PTR records for DHCP leases solves that problem.
In reality, reverse DNS tells you something but often not a great deal. Firms generally don't bother with their reverse DNS entries, so if your A record for www.mycompany.com resolves to A.B.C.D, you'll seldom find a PTR entry that tells the world that A.B.C.D reverse-maps to www.mycompany.com.
The university reference made me smile. In the 1990s one establishment (with its own /16 public IP range) assigned static public addresses to students in residences, and religiously added PTR records to reverse-map them to building, room and floor. Until a third-year IT student pointed out that this was a handy way for pervs to track down vulnerable people in their residence rooms. Them were the days before NAT firewalls and extensive use of private addressing.
To mitigate these risks, the researchers argue that DHCP client-provided information, such as device names, should not be mapped to publicly accessible PTR records.
I started thinking this right when the article mentioned a reverse name of toms-iphone12.example.edu. What admin in his or her right mind would map a CLIENT-provided hostname to a PUBLIC DNS PTR record on a DYNAMICALLY assigned IP address? Did it really take some overly complicated study to come to this conclusion? In >99% of the cases, rDNS PTR records should be statically assigned, and they don't need to be changed unless there is some structured process (i.e. manual admin intervention or a form someone has to fill out).
Honestly, I think the more interesting threat would be from INSIDE the network when using NAT. If you are dynamically assigning private IP addresses with dynamic hostname updates and allowing rDNS queries from within, you could potentially cause a lot more damage, since you are already inside the LAN. If some admins are unwise enough to allow public PTR records to get updated, I'd be willing to bet there are some that don't provide some sort of client isolation on the LAN side, which means if someone comes on with an unprotected device without a firewall (hey, like a phone), it's game on.
They documented for the academic community something that has been well known in industry for decades?
Also, I didn't read the paper but I wonder if they bothered to mention the vastly increased risks, in this day and age, of having end devices exposed on the public IPv4 space in the first place? From that point of view their paper might as well have been titled "how to pick a lock when the window has been left wide open".
Sort of like when you are on a train and the WiFi shows the names of peoples devices and they often have the owners name included. If you were so inclined going upto someone and saying "Hi xxxx " when you think you have narrowed it down to a likely individual is not a good thing. IMHO
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
