libes@cme.nist.gov (Don Libes) (12/10/90)
In perusing our ftp logs, we are trying to figure out who some of the hosts really are. About 80% of the IP addresses are successfully mapped back to fully- qualified domain names (FQDN) by ftpd. We've found that connecting to a host's smtp port often yields its name, too. Between the two of those, only 2 hosts in 1000 couldn't be mapped to a FQDN. Unfortunately, some of the names aren't very descriptive. We'd like to be able to give a domain to some piece of software and have it tell us what it is. (I.e. "nist.gov" => "National Institute of Substandard Technology, Gaithersburg, MD".) The whois database at nic.ddn.mil is a start. It knows all of the subdomains in the .edu, .com and some other domains. It seems most knowledgeable about the .mil domain, returning information about even subdomains within the subdomains of .mil. On the other hand, it knows very little about the geographical domains. For example, it could tell us that .AT was Austria and .CA was Canada, but it didn't seem to know subdomains within those. It could tell us the domain name servers for those domains, but none of them run a whois service like nic.ddn.mil. Is there some way to get this information, short of bothering the human zone contact for a domain? In the meantime, we've been translating FQDNs to IP numbers and then asking the NIC what it knows about the net (i.e., "whois net 129.6.32"). In the case of non-US hosts, this is much more informative than a domain query, yet it is much less informative than getting a real answer to the domain question. Don Libes libes@cme.nist.gov ...!uunet!cme-durer!libes
enag@ifi.uio.no (Erik Naggum) (12/10/90)
In article <8698@muffin.cme.nist.gov> libes@cme.nist.gov (Don Libes) writes:
Unfortunately, some of the names aren't very descriptive. We'd like
to be able to give a domain to some piece of software and have it tell
us what it is. (I.e. "nist.gov" => "National Institute of Substandard
Technology, Gaithersburg, MD".)
It's time to rehash the old TXT RR, again, I see. It can be used for
this purpose; it can be used to present your ICBM address (longitude
and latitude); it can hold whatever you want it to hold. It's real
neat, and totally underutilized.
To show how really neat it can be, you can put in a TXT RR for
cme.nist.gov, explaining what "CME" means, and another with the exact
location of the domain (if applicable).
People will immediately and intuitively see how useful this is, and do
the same thing _within_days_, so we could have some real, useful
information about hosts _everywhere_. Or am I full of dreamstuff?
--
[Erik Naggum] Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions. Wail: +47-2-836-863 ISO 8859-1: [\] FXE FXE {|} fxe fxeslevy@POINCARE.GEOM.UMN.EDU (12/11/90)
Erik Naggum <erik@naggum.uu.no> wrote: > ... To show how really neat it can be, you can put in a TXT RR for > cme.nist.gov, explaining what "CME" means, and another with the exact > location of the domain (if applicable). ... Beware: the TXT RR is unknown to the BIND 4.8 server, which is still pretty widespread. It may be unknown to some later versions too, I haven't checked. If you use TXT RR's run BIND 4.8, or the secondaries for your server run 4.8, you'll lose! This is probably the reason several people, including Paul Pomes at UIUC and we at UMN, use HINFO rather than TXT RR's to store miscellaneous text in the DNS -- it's kludgy but effective. Stuart Levy, Geometry Group, University of Minnesota slevy@geom.umn.edu
erik@naggum.uu.no (Erik Naggum) (12/11/90)
> Beware: the TXT RR is unknown to the BIND 4.8 server, which is still > pretty widespread. It may be unknown to some later versions too, I > haven't checked. If you use TXT RR's run BIND 4.8, or the secondaries > for your server run 4.8, you'll lose! This is probably the reason > several people, including Paul Pomes at UIUC and we at UMN, use HINFO > rather than TXT RR's to store miscellaneous text in the DNS -- it's > kludgy but effective. Aaarggh! I thought it would be enough to write an SMTP implementation for UNIX platforms. Now it seems it's necessary to write a DNS implementation, too. (By "implementation," I don't mean something which can successfully mislead the amateur into believing it's conformant, but a true, full, by-the-spec, robust implementation.) Sigh. [Erik Naggum] Naggum Software, Oslo, Norway
steve@UMIACS.UMD.EDU (Steve D. Miller) (12/13/90)
Sorry to eat up bandwidth with this, but it seems that lots of people don't know: the latest version of BIND (4.8.3, which I suppose is also known as 4.8.3.1, depending on what you look at) does support TXT records. The support is not perfect. However, the protocol-related part of the support (i.e., the way the bits look on the wire) is right, so far as I know. The MIT Hesiod servers also know about TXT records (and they're even right now, as a side-effect of the BIND 4.8.3 development effort). Probably the UT BIND supports TXT, too, but I haven't looked at it recently... -Steve P.S.: While I'm cluttering up the net, has anyone implemented for BIND the new RR types from RFC 1183? I know about the AFSDB implementation. Spoken: Steve Miller Domain: steve@umiacs.umd.edu UUCP: uunet!mimsy!steve Phone: +1-301-405-6736 USPS: UMIACS, Univ. of Maryland, College Park, MD 20742
he@spurv.runit.sintef.no (Havard Eidnes) (12/14/90)
In article <1990-344-45711@uunic.uu.no>, erik@naggum.uu.no (Erik Naggum) writes: |> In article <9012110031.AA11352@warschawski.geom.umn.edu>, |> slevy@POINCARE.GEOM.UMN.EDU (Stuart Levy) writes: |> > Beware: the TXT RR is unknown to the BIND 4.8 server, which is still |> |> Aaarggh! I thought it would be enough to write an SMTP implementation |> for UNIX platforms. May I remind you that BIND 4.8.3 has support for TXT records. However, the claim that its predecessors (4.8, 4.8.1) are still in widespread use is still valid, and that's probably not going to change overnight. - Havard