read-rfc1918-for-details.iana.net
Dave Gresham
message as the hostname for my intranet ip address' of
10.0.0.X and it is causing havoc with tcp wrappers, and
i also had another client with the same problem where i
was extracting the ip address with a 'who -m -x' to
assign a terminal id in Basis BBX based on the ip address.
my /etc/resolv.conf looks like
domain dbs1.com
hostresorder local bind
nameserver 209.98.98.98
nameserver 196.6.1.2
i am not running dns on the machine, and these address' are not in the
/etc/hosts file.
before i would get
username ttyp0 apr 19 16:42 10.0.0.19
now i get
username ttyp0 apr 21 17:00 read-rfc1918-for
does anyone know why the internet dns is returning this?
dave
Jeff Liebermann
>in the last 24 hour hours, I have started receiving the above
>message as the hostname for my intranet ip address' of
>10.0.0.X and it is causing havoc with tcp wrappers,
IANA.NET is the Internet Assigned Number Authority which allegedly runs the
IP numbers game.
Did you read RFC1918? 10.0.0.x are not *YOUR* IP addresses. They're part
of one of the non-routeable IP address blocks that are intended solely and
specifically for internal networks. None of these addresses are ever
expected to be routed by anything on the internet. In theory, you should
not be able to ping any machine in the entire 10.x.x.x block. If your try
traceroute, it should always end at your ISP's router.
What's happening is that your machines(s) are going out to your ISP's DNS
server and are trying to resolve your internal 10.0.0.xxx addresses instead
of resolving them locally. In the past, it would get no answer and default
to whatever is in /etc/hosts. Now, someone has elected to supply an answer
to your DNS queries.
Your lookup order is correct:
hostresorder local bind
It should look in /etc/hosts first. However, since the machines are not in
your /etc/hosts, your machines(s) use the last resort lookup and get their
answer from DNS. Are you connecting to your internal machines by name or
by IP address?
The first step should probably be to find out from where the
"read-rfc1918-for-details.iana.net" reverse DNS lookups are coming from.
From your resolv.conf, I find that your nameservers are:
209.98.98.98 is ra.visi.com
196.6.1.2 does not resolve, can't be pinged, and appears dead. Huh?
Using "dig", I find that read-rfc1918-for-details.iana.net doesn't
resolved, but 10.0.0.19 is alive and well and being resolved by both
ISI.NET and Internic.net. Looks official to me.
Dig 19.0.0.10.i...@209.98.98.98 ...
Non-authoritative answer
Recursive queries supported by this server
Query for 19.0.0.10.in-addr.arpa type=255 class=1
19.0.0.10.in-addr.arpa PTR (Pointer) read-rfc1918-for-details.iana.net
10.in-addr.arpa NS (Nameserver) BLACKHOLE.ISI.EDU
10.in-addr.arpa NS (Nameserver) NS2.INTERNIC.net
BLACKHOLE.ISI.EDU A (Address) 128.9.64.26
NS2.INTERNIC.net A (Address) 198.41.0.11
Dig read-rfc1918-for...@209.98.98.98 ...
Authoritative Answer
Recursive queries supported by this server
Authoritative answer: Host doesn't exist
Query for read-rfc1918-for-details.iana.net type=255 class=1
IANA.net SOA (Zone of Authority) Primary NS:NS.ISI.EDU Responsible
person:ia...@iana.org
serial:19981110
refresh:43200s (12 hours)
retry:3600s (60 minutes)
expire:1209600s (14 days)
minimum-ttl:86400s (24 hours)
I guess I should complain to Internic that their cute name doesn't resolve
properly. Meanwhile, you're stuck with this mess and will need to either
run your own DNS for your internal network, add every machine to every
/etc/hosts, or figure out why your machine(s) are not resolving your local
addresses properly.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
David Woolley
Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote:
>
>What's happening is that your machines(s) are going out to your ISP's DNS
>server and are trying to resolve your internal 10.0.0.xxx addresses instead
>of resolving them locally. In the past, it would get no answer and default
>to whatever is in /etc/hosts. Now, someone has elected to supply an answer
>to your DNS queries.
I can think of at least two reasons for doing this:
- these addresses often come up in traceroutes for spammers, as quite
legitimate ISPs use them for the networks connecting their incoming
and outgoing routers; resolving them will make it clearer to the victims
as to why they weren't getting a name for the router, and less likely to
assume the first such address is that of the spammer.
- failed DNS lookups are only cached for a short time, so anyone doing what
the original questioner was doing and trying to resolve the addresses
on the global internet will have been contributing to the overloading
of the root nameservers.
Jeff Liebermann
Liebermann) wrote:
>Using "dig", I find that read-rfc1918-for-details.iana.net doesn't
>resolved, but 10.0.0.19 is alive and well and being resolved by both
>ISI.NET and Internic.net. Looks official to me.
>
>Dig 19.0.0.10.i...@209.98.98.98 ...
>Non-authoritative answer
>Recursive queries supported by this server
> Query for 19.0.0.10.in-addr.arpa type=255 class=1
> 19.0.0.10.in-addr.arpa PTR (Pointer) read-rfc1918-for-details.iana.net
> 10.in-addr.arpa NS (Nameserver) BLACKHOLE.ISI.EDU
> 10.in-addr.arpa NS (Nameserver) NS2.INTERNIC.net
> BLACKHOLE.ISI.EDU A (Address) 128.9.64.26
> NS2.INTERNIC.net A (Address) 198.41.0.11
Well, methinks your troubles may be over. While the above mess was being
returned on Thursday, on Saturday we no get nothing (which is the way it
was earlier). Same name server (yours) and same query for 10.0.0.19, but
this time I get "Host doesn't exist".
Dig 19.0.0.10.i...@209.98.98.98 ...
Authoritative Answer
Recursive queries supported by this server
Authoritative answer: Host doesn't exist
Query for 19.0.0.10.in-addr.arpa type=255 class=1
10.in-addr.ARPA SOA (Zone of Authority) Primary NS:blackhole.isi.edu
Responsible person:bman...@isi.edu
serial:19971502
refresh:10800s (3 hours)
retry:900s (15 minutes)
expire:604800s (7 days)
minimum-ttl:86400s (24 hours)
I don't follow the ISO Layer 8 (political) network news. Duz anyone know
what really happened? Just curious.