pvm@VENERA.ISI.EDU (Paul Mockapetris) (03/15/90)
> Now that I can use the DNS to look up host names, it seems sort of > silly for getnetbyname() and getnetbyaddr() to be doing linear > searches through /etc/networks every time I do a "netstat -r". > > Has anyone implemented these functions in a way that uses the DNS to > translate back and forth between network names (e.g., ARPANET) and > network numbers (e.g., 10.0.0.0)? Some analogue to the .IN-ADDR.ARPA > domain (NET-ADDR, maybe?) would be appropriate for mapping numbers to > names. It would also be a good idea to invent a zone (NET-NAME?) for > the names to keep them out of the root domain. Comments and/or > pointers to any relevant RFCs would be appreciated. > > Warning: obviation of /etc/services and /etc/protocols is next. > > :: Jeff Makey See RFC 1101, "DNS Encoding of Network Names and Other Types" Although I wrote it up, the ideas were a combination arrived at by consensus of the IETF DNS WG. Note that although we have a definition, it is not used, mostly because of the chicken-and-egg problem: we don't use it because the data isn't there and we don't bother to put the data there because it isn't used. (The RFC is also wrong in that it assumes that subnet masks are hierarchical or otherwise well-behaved.) Now if you want to get seriously into this, check out Hesiod and lose your /etc/passwd. paul
philipp@GIPSI.GIPSI.FR (Philippe Prindeville) (03/15/90)
What about putting in 4.4BSD a new version of getnetent(3X) that uses the DNS a` la RFC-1101? Surely that would solve the chicken- and-the-egg problem, but we would have entropy against us... -Philip
pvm@ISI.EDU (Paul Mockapetris) (03/16/90)
The point is that the code will have nothing to look up unless somebody puts the data there. My view of what RFC1101 should have done was to have a NIC-created database which served as either a backstop or an initial database which would be delegated away a la IN-ADDR.ARPA. The folks at the meeting were adamant that the data be in the already allocated IN-ADDR.ARPA name space so that no new domains need be created. Of course, the NIC wasn't thrilled by a new job to do. paul
philipp@GIPSI.GIPSI.FR (Philippe Prindeville) (03/16/90)
The point is that the code will have nothing to look up unless somebody puts the data there. Yes, I understand. By utilizing it (via the 4.4BSD getnetent() function) one creates a demand for it (perhaps), and hopefully people will put the data where they ought to. My view of what RFC1101 should have done was to have a NIC-created database which served as either a backstop or an initial database which would be delegated away a la IN-ADDR.ARPA. And yes, you can prep IN-ADDR.ARPA with data from the hosttable, but it will become out of data unless people get into the habit of maintaining it (and even though gethostbyaddr() uses the IN-ADDR.ARPA domain, that in itself has not assured that everyone maintains their domain space). Part of the problem is that when most people register a domain, they are not compelled (by their top-level domain's authority or even by disgruntled users) to maintain this information. Even if the process of registration required that the database be set-up, that would still not guarrantee that it was keep up-to-date. The name of the game is "entropy". Perhaps inverse queries (despite the computational burden) would have been the "right" way to go. Once network management takes off (ie. SNMP is as widespread as RIP unfortunately is), then perhaps we will start seeing RFC-1101 in use. The folks at the meeting were adamant that the data be in the already allocated IN-ADDR.ARPA name space so that no new domains need be created. Of course, the NIC wasn't thrilled by a new job to do. Yes, it's funny how these distributed databases increase the burden on the NIC... -Philip
philipp@GIPSI.GIPSI.FR (Philippe Prindeville) (03/20/90)
[35] [4:30pm] cheops:/n/giza/0/karl> host 128.146.0.0 Name: net.ohio-state.edu Address: 128.146.0.0 Aliases: Karl: I believe your net entry is slightly incorrect -- the name returned by DNS should be *exactly* the same as that returned in the NetName field of the WHOIS database or the first field of the HOSTS.TXT file of the NIC, ie. for your address 128.146 it should be "OHIO-STATE". At least, this is by my reading of RFC-1101. Anyone can correct me... Anything stopping network hostmasters from creating their appropriate zero-address entries within in-addr.arpa already? Just the usual -- inertia. -Philip
enger@SCCGATE.SCC.COM (Robert M. Enger) (03/21/90)
Gents: I know of atleast one system that provides some sort of output: Bill Melohn's DNS based shared C library, for SunOS. With an /etc/networks file containing only a loopback entry, a netstat -r returns mostly numeric entries, but it DOES find a few hearty souls that have spent the time to put their network info into the DNS. It even shows my local subnets. (the following is highly abridged/truncated. The DNS entries are very sparse!) To the best of my understanding of the workings, it looks like even some fairly important networks have not been entered into the DNS. For instance, Arpanet, Milnet, Stanford's net-36, and even ISI's own 128.9.0.0. (I find the latter hard to believe, given that Paul wrote the spec. Maybe I'm doing something wrong?) Routing tables Destination Gateway Flags Refcnt Use Interface uionet.uio.no Ring3.wtp.contel.com UG 0 2 le0 Whse-ether.contel-wt Ring3.wtp.contel.com UG 0 3074 le0 Colo-GND-PP.contel-w Ring3.wtp.contel.com UG 0 221 le0 8.0.0.0 Ring3.wtp.contel.com UG 0 0 le0 128.8.0.0 Ring3.wtp.contel.com UG 1 203 le0 WTP-3North-ether.con Ring3.wtp.contel.com UG 0 0 le0 ProNet-80.contel-wtp Ring3.wtp.contel.com UG 0 1484 le0 hubnet.itd.nrl.navy. Ring3.wtp.contel.com UG 0 0 le0 Colorado-ether.conte Ring3.wtp.contel.com UG 0 1433 le0 btc.kodak.com Ring3.wtp.contel.com UG 0 0 le0 css-graminae.CSS.GOV Ring3.wtp.contel.com UG 0 0 le0 WTP-0South-ether.con Ring3.wtp.contel.com UG 0 0 le0 WTP-4South-ether.con Ring3.wtp.contel.com UG 0 0 le0 ISS-WTP-PP.contel-wt Ring3.wtp.contel.com UG 0 0 le0 NYU-NET Ring3.wtp.contel.com UG 0 0 le0 net.ohio-state.edu Ring3.wtp.contel.com UG 1 3 le0 10.0.0.0 sccgate UG 0 79 le0 WTP-4North-ether.con Ring3.wtp.contel.com UG 0 0 le0 WTP-0North-ether.con Ring3.wtp.contel.com UG 0 1662 le0 MIS-ProNet10.contel- Ring3.wtp.contel.com UG 0 0 le0 WTP-2North3-ether.co Ring3.wtp.contel.com UG 0 1692 le0 ALCIDE.CA Ring3.wtp.contel.com UG 0 0 le0 apollo-ring.inria.fr Ring3.wtp.contel.com UG 0 0 le0 zero-bnet.mitre.org Ring3.wtp.contel.com UG 0 0 le0 css-ring.CSS.GOV Ring3.wtp.contel.com UG 0 0 le0 WTP-1South-ether.con Ring3.wtp.contel.com UG 0 227 le0 WTP-5South-ether.con Ring3.wtp.contel.com UG 0 0 le0 brown-edu.brown.edu Ring3.wtp.contel.com UG 0 0 le0 css-ring.CSS.GOV Ring3.wtp.contel.com UG 0 0 le0 WTP-1South-ether.con Ring3.wtp.contel.com UG 0 227 le0 WTP-5South-ether.con Ring3.wtp.contel.com UG 0 0 le0 BRCAST.CS.YALE.EDU Ring3.wtp.contel.com UG 0 3 le0 36.0.0.0 Ring3.wtp.contel.com UG 0 1 le0 uwo-net.uwo.ca Ring3.wtp.contel.com UG 0 0 le0 ether.nrl.navy.mil Ring3.wtp.contel.com UG 0 1 le0 WTP-Colo-PP.contel-w Ring3.wtp.contel.com UG 0 0 le0 MCSNET-BCAST.BU.EDU Ring3.wtp.contel.com UG 0 3 le0 css-ether.CSS.GOV Ring3.wtp.contel.com UG 0 4 le0 WTP-2South-ether.con Ring3.wtp.contel.com UG 0 0 le0 net5-ether.contel-wt Ring3.wtp.contel.com UG 0 0 le0 HARRIS-SEMI Ring3.wtp.contel.com UG 0 0 le0 IRISA-NET.irisa.fr Ring3.wtp.contel.com UG 0 0 le0 paris-sud.fr Ring3.wtp.contel.com UG 0 0 le0
postel@VENERA.ISI.EDU (03/22/90)
Bob: Where is the evidence about ISI's net (128.9) not being registered? Your message shows net 128.8 (U. Maryland). --jon.