Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!ucsd!ucbvax!ERG.SRI.COM!davy From: davy@ERG.SRI.COM Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: HINFO record consistency Message-ID: <9011302233.AA11478@intrepid.erg.sri.com> Date: 30 Nov 90 22:33:52 GMT References: <1990-333-78765@uunic.uu.no> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: inet Organization: The Internet Lines: 42 From: Erik Naggum Date: Fri, 30 Nov 1990 22:52:45 +0100 Subject: Re: HINFO record consistency > Well, this sounded like an interesting idea, so I went and FTPed the RFC, > and installed all the stuff in my name server. I have the following info > now for domain erg.sri.com, from a "dig erg.sri.com any" request: [ whole bunch of records deleted ] I think you missed a small point in RFC 1101. The idea is to make one PTR RR for ERG.SRI.COM pointing at your class B network, and vice versa, but NOT to point to all subnets. These would have their own IN-ADDR.ARPA PTR RRs pointing at the proper network name, such as ERG-SN-1.ERG.SRI.COM for subnet 1. With the aid of the A RRs for the network number, you can find those subnets easy enough, anyway. That is, the PTR RR should be: erg.sri.com. 86400 PTR 0.0.18.128.in-addr.arpa. You now have significantly less data to stuff into the reply packet, and I believe the problems you experience will go away. :-) [Erik] Well, we (erg.sri.com) don't own the class B... that belongs to our parent domain, sri.com. But, you're right, I may have misinterpreted something. I was looking on page 6 of the RFC, which shows an example for MCC.COM, listing several nets. But, now that I look more closely, those are all different class C nets, not subnets of the same class B. Guess I'll have to beat on the sri.com administrator to put the top-level things in, and go take those back out of my files. Bother. Thanks, --Dave