Well, duh!
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.
Biting the hand that feeds IT
