RE: prisoner.iana.org

[David Vincent <david.vincent () mightyoaks com>]

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