you said... >I've started noticing an entry in the event log on one >of my Windows XP workstations. I've tried finding >information regarding this on google (have seen others >with the problem, but no answers) & have also >contacted iana (but have yet to hear anything from >them). > >The box is trying to make DNS requests to >'prisoner.iana.org'. this is by design. see mark minasi's latest newsletter for what's going on and how to fix it. it is quoted below... http://www.minasi.com/ but you need to register to view... -d ---------- Who Is the Prisoner of IANA? I periodically hear from people who, in the process of troubleshooting some problem, decide to look in their event logs or other application logs find scary-looking references to a machine named "prisoner.iana.org;" for example, a few Google references include "...My SurfControl server tells me that my printserver keeps trying to contact prisoner.iana.org..." "...My printserver (Win2K, SP1) has recently begun connecting to prisoner.iana.org..." "Why is my Win2K DNS server constantly attempting to [communicate] with prisoner.iana.org (192.175.48.1) on tcp port 53? " By default, Windows 2000, XP and .NET Server 2003 systems try to register their dynamic DNS information. Now, I know that you know that, (if you read Chapter 7 of my book, anyway) but let's look more closely and be sure that we really do know what's going on. First, recall that there are both forward lookup zones and reverse lookup zones. On a forward lookup zone, you'd look up a host name and get an IP address in return. For example, when you punch "www.minasi.com" into your browser and the browser looks www.minasi.com up to get an IP address of 206.246.253.111 or 68.15.149.117, that was a forward lookup, a lookup in the forward lookup zone for minasi.com. Technically the DNS world would call that an "A record lookup," as the record that says "if you're looking for the machine named X, then its IP address is Y." There are also reverse lookups; you could, for example, fire up nslookup and type "set type=ptr," press Enter and then type "206.246.253.111" and you'll get back "www.minasi.com." You must first type "set type=ptr" because the reverse records, the ones that say "the machine with IP address Y is known by the DNS name X," are called "PTR records." But in order for you to do that reverse lookup, IP-to-name rather than the more common name-to-IP, someone must have created a zone for the range of IP addresses. You may recall that it's an odd-looking zone, with the IP addresses backwards and in-addr.arpa appended to it; for example, as I run a C network 206.246.253.0, my reverse lookup zone looks like 253.246.206.in-addr.arpa, and to find 206.246.253.111 you'd look for the "111" PTR record in that zone. Because 2K and later systems try to register both their forward and reverse lookup, rebooting my Web server would cause it to try to register both its host name in the www.minasi.com forward lookup zone and its IP address in the 253.246.206.in-addr.arpa reverse lookup zone. Now, in that example I referred to my Web server, which has a routable IP address. But the vast majority of PCs on the Internet don't have routable addresses; instead, they use an IP address in one of the three private IP address ranges set aside by RFC 1918: 10.0.0.0-10.255.255.255 172.16.0.0-172.31.255.255 192.168.0.0-192.168.255.255 The idea is that anyone can create a private intranet using these IP addresses and then they won't step on anyone else's addresses. But what happens if you give a Windows 2000 or later system an IP address in this range? It will first register its host name in the proper forward lookup zone. It does that by finding out which DNS server is the primary DNS server for the zone whose name matches the computer's DNS suffix. In English, that means that if you've given your computer with an IP address of 192.168.0.33 the name myserver.bigfirm.biz then your computer will ask its local DNS server, "who's the primary DNS server for bigfirm.biz?," and your local DNS server will venture out to the Internet to find the primary DNS server for bigfirm.biz, and, once it finds that answer, it returns it to your computer. Your computer then contacts that primary DNS server for bigfirm.biz directly and tries to register its name and IP with bigfirm.biz's DNS server -- "say, bigfirm.biz's primary DNS server, would you please create an A record for me, indicating that whenever someone wants to find 'myserver' in bigfirm.biz that I'm right here at 192.168.0.33?" And, if bigfirm.biz's DNS server allows it -- it might not because the server might not be configured to accept dynamic updates, or it might be AD-integrated and myserver might not be a member of the domain -- then the record goes into the zone. Now, in that particular bigfirm.biz example, the primary DNS server for bigfirm.biz is my DNS server, as I registered the name, and so it'd reject the update, as I've got the bigfirm.biz zone set up for static updates only. But remember the beauty of split-brain DNS; you could have decided to create your own bigfirm.biz zone on your local DNS server, in which case your system would never run across my DNS server, and, provided you enabled dynamic lookups, your system would have successfully registered. Once it's registered (or tried to register) its name in a forward lookup zone, your system would seek out the reverse lookup zone, whose name it derives from its own IP address and subnet mask, and so decides that it needs to find the primary DNS server for the 168.192.in-addr.arpa reverse lookup zone so that it can register its PTR record with that server. So, as before, your local DNS server searches the Internet's DNS servers to find the ONE server on ALL of the Internet who's the big dog for PTR records in the range of 192.168.x.x. And perhaps now you can see the problem. There are tons of private networks out there using the 192.168.x.x address range, and they're all non-routable. Referring back to my earlier example, There's only one machine with the routable address 206.246.253.111, but there are probably thousands of systems out there with the private IP address 192.168.0.33. Me knowing that you have an internal system named myserver.bigfirm.biz at address 192.168.0.33 would be of no value whatsoever, as I couldn't contact that machine anyway, so there wouldn't be a point in you registering that information on a publicly-visible DNS server. Worse yet, if every machine with IP address 192.168.0.33 all tried to register their information then you'd have a real mess. No, in reality the chances are good that you either don't give a hoot whether or not myserver.bigfirm.biz registers its PTR records, or the only systems that care about myserver.bigfirm.biz's PTR record are the other systems inside your intranet. The right thing to do, then, is to set up your own 168.192.in-addr.arpa zone -- configured to accept dynamic updates! -- on your internal DNS server. Then your systems will think that server is the official primary DNS server for 192.168.x.x reverse lookups, and register their PTR information without a problem, and without any mysterious event log references to prisoner.iana.org. By the way, in case you're wondering, I don't know how to tell a 2K system to register its A (forward) record and not its PTR (reverse) record, or if it's possible at all to do that. But this doesn't answer my initial question: what IS this prisoner.iana.org? Well, once RFC 1918 (and its predecessors, actually) came out, the IANA -- the old name, recall, for the folks in charge of handing out IP address blocks -- realized that they needed a "placeholder" in-addr.arpa zone for the three ranges of non-routable addresses. So they put zones named 10.in-addr.arpa, 16.172.in-addr.arpa, and 168.192.in-addr.arpa on a three DNS servers named blackhole-1.iana.org, blackhole-2.iana.org and prisoner.iana.org, at IP addresses 192.175.48.6, 192.175.48.42, and 192.175.48.1, and prisoner is set as the primary DNS server for the zones. Thus, if one of your systems with a 192.168.x.x address tries to register its PTR record then it will, unless you have a local DNS server with a 168.192.in-addr.arpa zone, end up trying to register with prisoner.iana.org -- which will reject the request. The bottom line is, don't worry about it in most cases. In one case, however, you MIGHT worry about it, if you were running an intranet with a dialup connection to the Internet. If your intranet systems have private addresses and you don't have a local reverse lookup zone for your private addresses then you will cause your systems to try to contact prisoner, which would trigger a dialup. And if you're connected via ISDN in some country not blessed with as low a set of telecomm rates as we enjoy in the US, then that could be a quite expensive proposition. Again, the answer in that case would either be to tell your system not to do dynamic updates at all, or to create a local DNS server with a dynamic 168.192.in-addr.arpa zone. ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Sep 09 2002 - 12:35:42 PDT