Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ucsd!hub.ucsb.edu!spectrum.CMC.COM!lars From: lars@spectrum.CMC.COM (Lars Poulsen) Newsgroups: comp.protocols.tcp-ip.domains Subject: Re: PTR records of gateways on the Internet Message-ID: <1991Jan10.230440.25431@spectrum.CMC.COM> Date: 10 Jan 91 23:04:40 GMT References: <1991Jan9.195641.17628@slcs.slb.com> <1991Jan10.051543.8831@mp.cs.niu.edu> Organization: Rockwell CMC Lines: 149 In article <1991Jan9.195641.17628@slcs.slb.com> 7thson@slcs.slb.com (Chris Garrigues) writes: Chris> I discovered that some administrators appear to have rather Chris> bizzare ideas of how to set up [DNS in-addr.arpa PTR] records. I, too, have been bothered by these. And I, too, have found *.NSF.NET to be a major violator. Chris> a) I found PTR records that pointed to names that weren't in the DNS. In article <1991Jan10.051543.8831@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: Neil> What, if anything, is wrong with that? Neil> If a system makes outbound telnet/ftp etc connections, good Neil> Internet manners requires that the system identify itself. Neil> If the same system refuses all inbound connections there Neil> is no reason for it to have an A-record. Neil> Indeed such a record might even be undesirable. All systems have some form of outgoing traffic. Even a "dumb router" will send ICMP messages. It is important for network troubleshooting to be able to identify the origin of this traffic. Suppose I find that one of my users complains that he cannot get mail to "friend@foo-bar.com". One of the first steps in problem determination will be a traceroute: traceroute to foo-bar.com (123.246.0.159), 30 hops max, 38 byte packets 1 hinge.cmc.com (131.143.18.97) 0 ms 0 ms 0 ms 2 local.gateway.net (131.143.18.98) 60 ms 60 ms 60 ms 3 128.111.253.10 (128.111.253.10) 60 ms 60 ms 40 ms 4 ucla-ucsb.cerf.net (134.24.107.104) 60 ms 80 ms 80 ms 5 sdsc-ucla.cerf.net (134.24.101.100) 100 ms 80 ms 100 ms 6 nss.sdsc.edu (132.249.16.10) 80 ms 180 ms 100 ms 7 129.140.75.6 (129.140.75.6) 140 ms 300 ms 140 ms 8 129.140.73.11 (129.140.73.11) 180 ms 180 ms 200 ms 9 129.140.72.9 (129.140.72.9) 260 ms 240 ms 260 ms 10 * * * 11 * * * 12 * * * 13 * * * At this point, I will be VERY interested in knowing where 129.140.72.9 is located, and who might be operating it. As it happens, there is in fact a PTR record for it, Name: Princeton.NJ.NSS.NSF.NET Address: 129.140.72.9 and if I know this, I can take steps to contact the NSFnet N.O.C. to find out more. Neil> Perhaps a case could be made that it should have an HINFO record. It will not help me much to know that the IP address belongs to a CISCO AGS/2 running software revision 8.1(2) ?? Neil> Or perhaps it should have a CNAME record identifying Neil> a system whose administrator manages the indicated system. It would in fact be helpful if we defined a HADMIN RR yielding a mailbox for the host administrator. The current DNS does not, however, provide such an RR. And the name returned by a *.IN_ADDR PTR RR should always be the canonical name. Neil> For example what do you do with a PC which is not always turned on, Neil> which is not running TCP software except when making outbound calls. Even a system which is not always available, generally has an identity. Neil> Or what do you do with 'dial SL/IP' where different hosts can share Neil> a common Internet address? This is a legitimate problem. But such hosts are typically end nodes, not intermediate systems. The best solution would probably be to have the PTR yield a name such as "PORT-15.SLIP-GW-2.FOO.BAZ". Chris> b) I found PTR records that pointed to names that mapped back to Chris> different addresses. And indeed, this is the case with the above example, and that is why TRACEROUTE is unable to resolve the name: princeton.nj.nss.nsf.net 13265 IN A 128.121.54.1 There is code in (at least Sun's) "gethostbyaddr()" to trap this type of data inconsistency and produce a syslog message: syslog: gethostbyaddr: Princeton.NJ.NSS.NSF.NET != 129.140.72.9 Obviously the implementors of gethostbyname() believed this to be illegal. Chris> c) Many of these addresses mapped into names which only had one address. Chris> This either means that no entry was made for the other name or the two Chris> names are entirely unlinked. I think this is true for ALL the *.NSS.NSF.NET routers. Neil> the samples that come with the bind software suggest you use a PTR Neil> to map 127.0.0.1 to 'localhost', and that you have an A-record Neil> mapping 'localhost.your.domain' to '127.0.0.1'. Neil> Isn't this the type of inconsistency you are complaining about? In fact his is entirely consistent. 127.0.0.1 -> localhost.my.domain; localhost.my.domain -> 127.0.0.1 Chris> Does anybody besides me think that a RFC that clarified what a domain Chris> administrator MAY, SHOULD, and MUST do would be useful to point at when Chris> stumbling over things like these. RFC-1033 (Nov-87) "Domain Operations Guide" already covers this. Quoth: [page 11] "Adding a host ... Add an entry for EACH address of the host ... Add the reverse IN-ADDR entry for each host address in the appropriate zone files for each network the host is on." [and] "Adding gateways. Follow instructions for adding a host. Add the gateway location PTR records for each network the gateway is on." This RFC is remarkably clear, and is remarkably overlooked. Let me quote from page 12: RFC> COMPLAINTS RFC> RFC> These are the suggested steps you should take if you are having RFC> problems that you believe are caused by someone else's name server: RFC> RFC> RFC> 1. Complain privately to the responsible person for the domain. RFC> You can find their mailing address in the SOA record for the RFC> domain. RFC> RFC> 2. Complain publicly to the responsible person for the domain. RFC> RFC> 3. Ask the NIC for the administrative person responsible for the RFC> domain. Complain. You can also find domain contacts on the NIC in RFC> the file NETINFO:DOMAIN-CONTACTS.TXT RFC> RFC> 4. Complain to the parent domain authorities. RFC> RFC> 5. Ask the parent authorities to excommunicate the domain. I guess we are now at step 2 :-) :-) I see little chance of succeeding with step 5 !! -- / Lars Poulsen, SMTS Software Engineer CMC Rockwell lars@CMC.COM