Michael D Schleif | 2 Feb 2006 14:52

Re: Multiple PTR records ???

Thank you, for those who pointed me to RFC 2181; where I found paragraph
10.2.  I do not know why I did not see this in my search.  Perhaps, in
chasing the problem I am trying to resolve, I was confused by what I saw
as ambiguity.  Now, I am absolutely clear that this is allowed.

Is it possible that you enlightened beings can help me with my original
problem that led me to this?

I am tasked by my client to implement an Enterprise Systems Management
(ESM) solution.  The software is comprised of several pieces.  This
software collects and correlates information about thousands of
applications, hosts and network objects (e.g., routers, switches,
firewalls, &c.)

Not all of these objects are in the corporate DNS.  Some of those that
are, have multiple PTR records.

Information about these objects comes to these various softwares,
including hostname and address attributes.  Some of these "events" are
first processed by an SNMP Manager; which first knows the object by its
address; then adds a hostname, prior to sending it on to the correlation
server.  Other events originate from an agent that resides on a host;
which publishes the event with a hostname attribute, as known to itself.
In this second case, the correlation server knows the address that sent
the event, and the hostname that the agent attributed to the event.

Furthermore, some of this software depends on one or both of the
following processes:

  [A] name -> gethostbyname -> address -> gethostbyaddr -> name2
(Continue reading)

Pete Ehlke | 2 Feb 2006 17:31

Re: Multiple PTR records ???

On Thu Feb 02, 2006 at 07:52:18 -0600, Michael D Schleif wrote:
>
>The problem comes when the software notifies administrators that a
>problem exists; and that somebody should be dispatched to resolve that
>problem.  When somebody receives a notification, and does NOT recognize
>the host by name; then, confusion sets in.
>
>
>I see three (3) possible solutions to this problem:
>
>[1] The Enterprise changes their name resolution policies and systems in
>    accordance with our requirements;
>
>[2] We build a wrapper around the ESM infrastructure to "normalize"
>    names and addresses; or
>
>[3] We utilize some heretofore-unknown-to-us DNS "tricks" to facilitate
>    the normalized names and addresses.
>
see RFC2100

See http://www.sun.com/blueprints/0501/Naming.pdf for an interesting
implementation.


Gmane