Discovering outside people attempting to do dynamic DNS updates to us
We run our own primary DNS servers for DNS for our zones, both forward zones for domains we support and reverse PTR zones for our public subnets. For a number of reasons, including that our network layout means we need split-horizon DNS, we have what I would call a semi-stealth DNS master server; it's not listed in our NS records, but it is listed as the master name server in our SOA records, including (of course) for reverse PTR zones. External people are not supposed to query this machine, but sometimes they do anyway and sometimes this is the symptom of a configuration problem, like the machine appearing in a NS record. So today, I decided to take a look on our perimeter firewall to see who was trying what these days. Much like other times I've done similar things (or), there were interesting things underneath this rock.
The most surprising thing to me was that most of the traffic our firewall was rejecting wasn't DNS queries, it was DNS UPDATE attempts. When I grabbed packet dumps and decoded them in Wireshark, they turned out to be attempts by various remote IPs to add reverse lookup information for various host names. More specifically, this looked like Windows dynamic DNS updates. Some of the updates were for machines in .LOCAL, but others were for host names in various domains, most of which seem to be real domains. Some of the host names were generic, like 'laptop-<jumble>', but others had a clear organized naming scheme or were even idiosyncratic, like 'WheelOfFortune'.
(There's one domain name that doesn't exist, but the name and the geolocation of the IP address it comes from strongly suggests that it's probably an internal name or a mangling of it that escaped into the outside world. The domain is 'ABGTOWNSHIP.com', and the IP address is reported as being in Abington PA.)
After looking at this for a while, I've come up with a moderately horrifying theory for what is causing this: I think that some people out there in the world have set up their internal networks to use part of the University of Toronto's class B 126.96.36.199/16 IP address space (it wouldn't be the first time). When Windows machines on these internal networks decide to do a dynamic DNS update to register themselves, they look up the SOA for the PTR of their subnet through public DNS, determine that it's our semi-stealth master (which is listed as the SOA MNAME for our PTR zones), and send it to us.
Whether or not update requests reach us at all likely depends on which parts of 188.8.131.52/16 are being used internally. If they're using the subnet that our semi-stealth master sits on, the update requests would probably not make it onto the public Internet. This matches the pattern of PTR zones that I saw in my limited monitoring, in that they never tried to update that subnet's PTR zone.
(In one case I was able to get results that supported this. A machine on the same subnet as they were trying to do a PTR update for could not reach the HTTP port on the IP trying the update, while machines on other subnets could.)
Our parts of 184.108.40.206/16 are very low in the address space (in fact mostly right at the start of it), for historical reasons that you can probably guess at. This probably makes us unusually likely to be affected by this, since people usually pick subnets from the bottom of broad IP address ranges (witness the eternal popularity of 192.168.1.0/24).
(This is likely the same sort of thing as we saw before with CBL mis-listings. But the last I'd seen of that was in 2014, so I'd hoped it was all over by now. I should have known better, but perhaps there's at least fewer people doing this.)
Comments on this page:Written on 30 April 2021.