Subject: Re: Schedule for remote operations work

From: Kenneth White <[email-masked]>
Date: Sun, 6 Sep 1998 13:28:26 -0400

Juergen,

>Well, I have not been in Chicago so I do not know the whole story, but
>I am not sure how much sense it makes to add the DNS lookup stuff. Is
>this really needed?

In Chicago I asked if allowing for a symbolic name as a target address,
or in the case of traceroute returning the DNS name of a hop, was needed.
I think the consensus was to remove this from the ping and traceroute tables
in order to simplify them, but the function of determining what a
symbolic name would resolve to or what the symbolic name of an address
is at a remote host would be useful. The issuer of a remote request may
not have access to the same DNS server(s) that a remote target does, also name
resolution can be locally defined at the target.

>DNS allows you to talk to non-local DNS servers in
>order to resolve names. You usually set a few parameters in your
>resolver library and you are done. Much faster and easier than doing
>complex operations on a MIB via SNMP. If we continue the MIB approach,
>I would also like to know if and how this interfaces with existing DNS
>MIBs.

I scanned though the DNS MIB RFCs: 1612 and 1611 (do like the dnsname TCs
that I may import them in the next version). Neither provide the function.
Didn't see any internet-drafts for DNS MIB support.

>BTW, the text in the new ID talks about gethostbyname() and
>gethostbyaddr() functions. This is not really correct if you want to
>do DNS lookups as these functions usually do a lot more than just DNS
>lookup.

I didn't worry about the address family specification that can be specified on
a gethostbyaddr() call or is returned in the hostent struct from gethostbyname()
since I would expect these to be AF_INET. I should of added more text to
the internet-draft but didn't have time. With these calls you do have the
capability to get back more than one answer. In the gethostbyname() case
hostent allows for multi-homed hosts as well as aliasing.  Instead of making
the dnsLookupTable more complicated I thought that returning either the
primary name (h_name from the hostent struct) for a gethostbyname call or
the first address (in h_addr_list from hostent) for a gethostbyaddr call
was sufficient.

Let me know if there is a better way of doing this. I certainly didn't want
to replicate the nslookup function via a MIB.

Ken

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 7 Sep 1998 17:20:21 +0200

>>>>> Kenneth White writes:

Kenneth> In Chicago I asked if allowing for a symbolic name as a
Kenneth> target address, or in the case of traceroute returning the
Kenneth> DNS name of a hop, was needed.  I think the consensus was to
Kenneth> remove this from the ping and traceroute tables in order to
Kenneth> simplify them, but the function of determining what a
Kenneth> symbolic name would resolve to or what the symbolic name of
Kenneth> an address is at a remote host would be useful. The issuer of
Kenneth> a remote request may not have access to the same DNS
Kenneth> server(s) that a remote target does, also name resolution can
Kenneth> be locally defined at the target.

Sounds like you want to return names coming from local name resolution
configuration files and probably from other naming services like NIS
in addition to DNS lookups. If this is true, than we should not call
it a DNS lookup MIB. Further, I think it is important to know exactly
what you got. Being able to get names of local significance which you
can't easily convert back later on seems questionable, especially if
you do not indicate what the response is based on (a DNS lookup, a
local configuration file, a NIS lookup,...).
							Juergen

Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)