Date: Mon, 1 Nov 1999 13:54:03 -0600 (CST) From: Alec Kloss <ajk@paw-in-eye.net> To: papalia@UDel.Edu (John) Cc: dan@dpcsys.com, freebsd-questions@FreeBSD.ORG Subject: Re: Reverse DNS lookup Message-ID: <199911011954.NAA05346@D2SI.COM> In-Reply-To: <4.1.19991031213125.009407e0@mail.udel.edu> from John at "Oct 31, 1999 9:33:50 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
John said:
> <snip>
>
> >> merlin# nslookup 63.224.53.3
> >> Server: copland.udel.edu
> >> Address: 128.175.xx.xx
> >> *** copland.udel.edu can't find 63.224.53.3: Non-existent host/domain
> >
> >That's cause there is no reverse for that IP. It's from a /25 subnet
> >and US West probably doesn't delegate less than a /24 for in-addr.arpa
Actually, they do, but they're not doing it exactly in line with the
RFC for reasons involving their internal DNS management software. I
had to get a friend of mine who works there to set it up. They use NS
records on each address to point it to your own nameservers. Check
out 63.224.10.1.
It does appear that 63.224.53.3 is not assigned a reverse.
> Could you do me a favor and explain all that? I have no idea what /25
> subnet and in-addr.arpa actually mean :)
/25 subnet means the first 25 bits of the address correspond to a
network and the last 7 correspond to a particular node on that
network. Once upon a time, it was assumed that addresses less than
127.0.0.0 were /8 (aka. Class A), but this is no longer true. It
appears that Network Solutions divided 63.x.x.x into /12
Default Server: localhost.d2si.com
Address: 127.0.0.1
> set type=ptr
> 224.63.in-addr.arpa
Server: localhost.d2si.com
Address: 127.0.0.1
224.63.in-addr.arpa
origin = ns1.uswest.net
mail addr = hostmaster.uswest.net
serial = 318
refresh = 28800 (8H)
retry = 7200 (2H)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
> 63.in-addr.arpa
Server: localhost.d2si.com
Address: 127.0.0.1
Authoritative answers can be found from:
IN-ADDR.arpa
origin = A.ROOT-SERVERS.NET
mail addr = hostmaster.INTERNIC.NET
serial = 1999110102
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)
The in-addr.arpa DNS domain is used for reverse lookups. The idea is
that reverse lookups should be delegated like forward ones are, in a
hierarchical fashion. So, to find the name for a given address, you
follow a hierarchy like this:
arpa contains in-addr contains 63 contains 224 contains 53 contains 3,
so you construct a DNS query for the name
3.53.224.63.in-addr.arpa.
Also, note that you are looking for a particular type of record, a PTR
record, so you should tell nslookup that using
set type=ptr
The problem with the above hierarchical scheme is that authority for
reverse lookups no longer necessarily falls at the dots. So, the
original scheme assumed that every address like 63.224.53.* was
controlled by the same entity. It is becoming increasingly common for
this not to be the case, so USWest is using a NS record to delegate
the responsibility, like this:
ajk@hamlet ~% nslookup
Default Server: localhost.d2si.com
Address: 127.0.0.1
> server ns1.uswest.net
Default Server: ns1.uswest.net
Address: 204.147.80.5
> set type=ns
> 1.10.224.63.in-addr.arpa
Server: ns1.uswest.net
Address: 204.147.80.5
Non-authoritative answer:
1.10.224.63.in-addr.arpa nameserver = hamlet.d2si.com
1.10.224.63.in-addr.arpa nameserver = othello.d2si.com
Authoritative answers can be found from:
hamlet.d2si.com internet address = 63.224.10.2
othello.d2si.com internet address = 63.224.10.1
> 3.53.224.63.in-addr.arpa
Server: ns1.uswest.net
Address: 204.147.80.5
*** ns1.uswest.net can't find 3.53.224.63.in-addr.arpa: Non-existent
host/domain
They clearly have not set this up yet for whoever this 63.224.53.3 box
is.
> And if that's the case (above) then that might be the problem on all my
> reverse lookups that go bad. In essence all the problems I'm having are
> with people using their desktops at work who ssh into my box. But when I
> try out nslookup on servers from, for example, my old ISP, it works fine
> both ways.
If you're saying that your old ISPs nameservers can resolve
63.224.53.3, they have probably assumed control of the network
erronously. If I am correct, your school should be able to resolve
63.224.10.1 (it can) but your old ISP will probably NOT be able to
resolve 63.224.10.1.
Hope this helps clear things up a bit.
> Thanks again!!!
> --John
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-questions" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911011954.NAA05346>