SUMMARY: auth.log entry: gethostby*.getanswer

From: Rainer Landes <rlandes_at_fphws03.physik.uni-karlsruhe.de>
Date: Mon, 28 Apr 97 09:55:27 +0200

Thanks to:
"Richard A. Muirden" <richard_at_rmit.EDU.AU>
 Eric Bennett <bennett_at_hpel.cees.edu>
Jim Belonis <belonis_at_dirac.phys.washington.edu>

Some days ago I asked:

Occasionally I get entries in auth.log like the following.
What do they mean?

Apr 22 15:19:47 fphws01 syslog: gethostby*.getanswer:
asked for "148.32.25.194.in-addr.arpa IN PTR", got type "CNAME"
Apr 22 15:19:47 fphws01 syslog: gethostby*.getanswer:
asked for "148.32.25.194.in-addr.arpa", got "148.128.32.25.194.IN-ADDR.ARPA"

==================

The answer was, that a www-proxy server contacted my www-server.
For this proxy server somewhere out there exists an incorrect entry in
its corresponding BIND name server.

nslookup 194.25.32.148

Name: proxy3.metronet.de
Address: 194.25.32.148
Aliases: 148.32.25.194.in-addr.arpa

When my www-server tried to look up the name for logging purposes,
it got these incorrect answers and the system logged the above
mentioned messages to auth.log.
=========================

Received answers:
----------
From: "Richard A. Muirden" <richard_at_rmit.EDU.AU>
...
because you can't have a PTR record point back to a CNAME. a PTR
record should point back to an actual A record:

eg:

zyx IN A 148.32.25.x
x IN PTR zyx.your.domain

etc
....
---------
From: "Richard A. Muirden" <richard_at_rmit.edu.au>
...
the nameserver (bind) would be misconfigured. ask whoever maintains
that for you to check it out.
>
> Please give me just a short hint:
> Where do I have to look?

the nameserver for your address...
-----------
From: Eric Bennett <bennett_at_hpel.cees.edu>
...
This means that the server for 194.25.32.148 used a CNAME record when
they should have used a PTR. I think you can safely ignore this.
(you might send a note to postmaster on the offending server).0
...
---------
From: Jim Belonis <belonis_at_dirac.phys.washington.edu>
...
DNS actually consists of two tables. The name->IPnumber translation table
and the IPnumber->name translation table.
The message means the 'DNS reverse table entry'
(i.e. number translation to name)
is not consistent with the DNS entry for the name
(i.e name translated to number).

So someone has screwed up the DNS reverse table. Usually this means
someone didn't update it when the machine's IP number changed.
But in your case, the number->name translation is giving another number
which is something I have never seen before.
It looks like someone is deliberately attempting to give an IP number
an alias so two IP numbers act the same. I doubt this works.

You should probably contact the owner of the problem machine(s).

You can look at the DNS tables with the nslookup program (on most unix)

nslookup
set type=any
proxy3.metronet.de

will show the DNS entry translating that name to one of the problem numbers.
This is the 'real' IP address of the machine 194.25.32.148 .
and

nslookup
set type=ptr
148.32.25.194.in-addr.arpa

will show the reverse translation (number to name).

Note in the query, the number is octet-wise reversed, then .in-addr.arpa
is appended. Also the query type is 'ptr' to get the reverse table.
...

==================
Rainer Landes, eMail: Computer-Administration_at_Physik.uni-karlsruhe.de
Tel(+49)721 608 3578 http://www-comp.physik.uni-karlsruhe.de/
Computer facilities of the Faculty of Physics, Univ. of Karlsruhe, GER
Received on Mon Apr 28 1997 - 10:16:07 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:36 NZDT