7thson@slcs.slb.com (Chris Garrigues) (01/10/91)
I was recently trying to map out some of the internet. I was doing this
by identifying the IP address of gateways with low TTL pings and looking
at the from address of the returning TTL-exceeded packets. I then tried
to use IN-ADDR.ARPA reverse mappings to map these into names and from
there, I tried to find the other interfaces of the gateways by finding
the A records for those names.
Needless to say, in the process, I discovered that some administrators
appear to have rather bizzare ideas of how to set up these records.
a) I found PTR records that pointed to names that weren't in the DNS.
b) I found PTR records that pointed to names that mapped back to
different addresses.
c) Many of these addresses mapped into names which only had one address.
This either means that no entry was made for the other name or the two
names are entirely unlinked.
Does anybody besides me think that a RFC that clarified what a domain
administrator MAY, SHOULD, and MUST do would be useful to point at when
stumbling over things like these. Examples might be:
The name referenced by a PTR record MUST have an A record containing the
address corresponding to the PTR record.
If a host or gateways has multiple addresses, these addresses SHOULD
have PTR records pointing either to the same name OR to names with CNAME
records pointing to a common name.
Chris Garrigues,
Schlumberger Laboratory for Computer Scienceckd@cs.bu.edu (Christopher Davis) (01/10/91)
Chris> == 7thson@slcs.slb.com (Chris Garrigues) writes:
Chris> I was recently trying to map out some of the internet. [...]
Chris> a) I found PTR records that pointed to names that weren't in the DNS.
Chris> b) I found PTR records that pointed to names that mapped back to
Chris> different addresses.
And one of the big offenders here? The NSFNET NSSes!
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.
And, once again, the biggest offender? *.NSS.NSF.NET!
How to you expect the regionals and campus networks to get this right
when the folks who pass the long haul stuff don't seem to be bothering?
(No, Chris, I'm not berating you. I'm displeased with these results too.)
--
[ Christopher Davis - <ckd@cs.bu.edu> - <..!bu.edu!cs.bu.edu!ckd> ]
A message destined for delivery in *your* domain is fair game for
anything you may want to do, up to and including translating the entire
message, header and all, into Swahili. -- chip@tct.uucp (Chip Salzenberg)rickert@mp.cs.niu.edu (Neil Rickert) (01/10/91)
In article <1991Jan9.195641.17628@slcs.slb.com> 7thson@slcs.slb.com (Chris Garrigues) writes: >(...) >Needless to say, in the process, I discovered that some administrators >appear to have rather bizzare ideas of how to set up these records. > >a) I found PTR records that pointed to names that weren't in the DNS. > What, if anything, is wrong with that? If a system makes outbound telnet/ftp etc connections, good Internet manners requires that the system identify itself. If the same system refuses all inbound connections there is no reason for it to have an A-record. Indeed such a record might even be undesirable. Perhaps a case could be made that it should have an HINFO record. Or perhaps it should have a CNAME record identifying a system whose administrator manages the indicated system. For example what do you do with a PC which is not always turned on, which is not running TCP software except when making outbound calls. Or what do you do with 'dial SL/IP' where different hosts can share a common Internet address? >b) I found PTR records that pointed to names that mapped back to >different addresses. This is exactly what you would expect in the suggested example above if the name on the PTR were a CNAME for another system with the same administrator. >c) Many of these addresses mapped into names which only had one address. >This either means that no entry was made for the other name or the two >names are entirely unlinked. Perhaps they are administratively linked. You might start by looking at an example I brought up (with no satisfactory response) in the bind mailing list. Specifically the samples that come with the bind software suggest you use a PTR to map 127.0.0.1 to 'localhost', and that you have an A-record mapping 'localhost.your.domain' to '127.0.0.1'. Isn't this the type of inconsistency you are complaining about? >Does anybody besides me think that a RFC that clarified what a domain >administrator MAY, SHOULD, and MUST do would be useful to point at when >stumbling over things like these. Examples might be: > While I agree some clarification is needed, it cannot be a precise as you would like. The Internet has evolved in ways probably not envisioned when 'bind' was designed. Personally I am much more troubled by the cases where the different name servers for a domain have mutually inconsistent data - presumably reflecting an intermural dispute within the domain. (In at least one case I know this is not just a matter of delayed updating, unless the TTLs are 1 year or more). -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
kwe@bu-it.bu.edu (Kent England) (01/11/91)
In article <CKD.91Jan9220223@bucsd.bu.edu>, ckd@cs.bu.edu (Christopher Davis) writes: > > Chris> b) I found PTR records that pointed to names that mapped back to > Chris> different addresses. > > And one of the big offenders here? The NSFNET NSSes! > > How to you expect the regionals and campus networks to get this right > when the folks who pass the long haul stuff don't seem to be bothering? > One of the nicest features of the inverse mapping of the backbone IP addresses is that traceroute will give you a nice name for the NSS interface as you traverse the Internet. You will be able to figure out where your path goes. It is an excellent argument for having intelligible gateway interface names throughout the Internet. For those who run the backbone, one of the nicest features of the lack of an A record for that name is that there is less likelihood that people will pour pings, telnet, ftp, and mail messages at the gateways. They still can, but it must be to an IP address and not a name. All in all a nice compromise, in my opinion. --Kent
ckd@cs.bu.edu (Christopher Davis) (01/11/91)
Kent> == Kent England <kwe@bu-it.bu.edu>
Kent> One of the nicest features of the inverse mapping of the
Kent> backbone IP addresses is that traceroute will give you a nice
Kent> name for the NSS interface as you traverse the Internet. You
Kent> will be able to figure out where your path goes. It is an
Kent> excellent argument for having intelligible gateway interface
Kent> names throughout the Internet.
Kent> For those who run the backbone, one of the nicest features of
Kent> the lack of an A record for that name is that there is less
Kent> likelihood that people will pour pings, telnet, ftp, and mail
Kent> messages at the gateways. They still can, but it must be to an
Kent> IP address and not a name.
Kent> All in all a nice compromise, in my opinion.
Except that (1) SunOS 4.1's gethostbyaddr wants an A record for added
security against DNS spoofing (admirable, but non-optimal when you just
want whatever PTRs are out there...), and (2) there ARE A records out
there, for the other interfaces. Example:
; <<>> DiG 2.0 <<>> Ann_Arbor.MI.NSS.NSF.NET
;; [...]
;; Ann_Arbor.MI.NSS.NSF.NET, type = A, class = IN
;; ANSWERS:
Ann_Arbor.MI.NSS.NSF.NET. 14400 A 35.1.1.50
but...
; <<>> DiG 2.0 <<>> -x
;; [...]
;; 8.81.140.129.in-addr.arpa, type = ANY, class = IN
;; ANSWERS:
8.81.140.129.in-addr.arpa. 9726 PTR Ann_Arbor.MI.NSS.NSF.NET.
[...]
In other words, neither half of the compromise is being served. The NSF
isn't "secured" from people pounding on the NSSes, and I don't get
symbolic names from traceroute without compiling with a different
-lresolv (read: not Sun's).
I'm not sure both sides *can* be served given the situation, but "They"
should definitely choose one or the other...
(Aside: doing a PTR lookup on the A record returned for
"Ann_Arbor.MI.NSS.NSF.NET" gets me... "nss17.merit.edu". Consistency in
the backbone does not seem to be a particular priority...
--
[ Christopher Davis - <ckd@cs.bu.edu> - <..!bu.edu!cs.bu.edu!ckd> ]
A message destined for delivery in *your* domain is fair game for
anything you may want to do, up to and including translating the entire
message, header and all, into Swahili. -- chip@tct.uucp (Chip Salzenberg)lars@spectrum.CMC.COM (Lars Poulsen) (01/11/91)
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
rickert@mp.cs.niu.edu (Neil Rickert) (01/11/91)
In article <1991Jan10.230440.25431@spectrum.CMC.COM> lars@spectrum.CMC.COM (Lars Poulsen) writes: > >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. > This is why it is appropriate to have PTR records, even when it is not appropriate to have A records mapping the name back to the address. >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: Just because Sun's 'gethostbyaddr()' is broken, there is no reason to complain about the way domains are set up. >Obviously the implementors of gethostbyname() believed this to be >illegal. > The public BSD sources do not have this defect. The DNS is a directory service, not an authentication service. The extra checking you describe in Sun gethostbyname() is an attempt to use it as an authentication service. This is WRONG behavior for gethostbyaddr(). It may make sense to add this type of authentication to some specific uses (say in rlogind, when checking hosts.equiv). But it does not make sense in general. To use an admittely imperfect analogy, just because I announce who I am when I initiate a telephone call, this does not mean I may not have an unlisted number. >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 > Look again at the samples. They mostly map 127.0.0.1 to 'localhost', and NOT to 'localhost.your.domain', and for good reason. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
mdb@ESD.3Com.COM (Mark D. Baushke) (01/11/91)
On 10 Jan 91 20:38:58 GMT, ckd@cs.bu.edu (Christopher Davis) said: [...] ckd> ;; ANSWERS: ckd> Ann_Arbor.MI.NSS.NSF.NET. 14400 A 35.1.1.50 [...] ckd> ;; ANSWERS: ckd> 8.81.140.129.in-addr.arpa. 9726 PTR Ann_Arbor.MI.NSS.NSF.NET. [...] Very interesting... I do not believe that any of the RFCs have extended the name syntax to allow an underscore (_) character in a name. I know that RFC 1123 section 2.1 allowed such names to begin with a digit (so 3Com.COM became legal), but I believe that the name Ann_Arbor.MI.NSS.NSF.NET voilates the syntax in the RFCs. As far as I know, RFC 952 together with the relaxation in RFC 1123 say that a "name" is a text string drawn from the alphabet (A-Za-z), digits (0-9), minus sign (-), and period (.). It looks to me like the NSSes have more than one problem with their entries. -- Mark mdb@ESD.3Com.COM
ejm@ejmmips.NOC.Vitalink.COM (Erik J. Murrey) (01/12/91)
In article <CKD.91Jan10153858@bucsd.bu.edu>, ckd@cs.bu.edu (Christopher Davis) writes: > Except that (1) SunOS 4.1's gethostbyaddr wants an A record for added > security against DNS spoofing (admirable, but non-optimal when you just > want whatever PTRs are out there...), and (2) there ARE A records out > there, for the other interfaces. Example: > I think this may be overkill on the part of Sun. I agree that for semi-secure applications, a reverse check is necessary to insure that the DNS admins aren't faking host names. (i.e. the rexec and rcmdservices + rlogin benifiit from this check) However, for other applications such as mail, finger, traceroute, etc, this double-check is unecessary. Sun should have done more research into the impact of this unexpected change before shipping it with a major release of software. ---- Erik Murrey Vitalink Communications NOC ejm@NOC.Vitalink.COM, uunet!vitam6!noc.vitalink.com!ejm
medin@nsipo.arc.nasa.gov (Milo S. Medin) (01/13/91)
In article <1991Jan11.004226.24988@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >> >>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: > > Just because Sun's 'gethostbyaddr()' is broken, there is no reason to >complain about the way domains are set up. > >>Obviously the implementors of gethostbyname() believed this to be >>illegal. >> > The public BSD sources do not have this defect. > > The DNS is a directory service, not an authentication service. The This is not broken, nor is it a defect, and nor is it limited to SUN's. We at Ames came up with this mod to the resolver code after having been burned by internet DNS spoofing. If your resolver doesn't have this capability, your site is open to a lot of security problems. We have BSD systems here which had the mod made to the resolver and had network utilities rebuilt. We turned this bug into Sun, and posted it on comp.bugs.4bsd. Many sites use this since they consider security marginally important. If you don't, that's fine, and more power to you, but don't berate the efforts of a vendor who is concerned with improving the state of security. If you don't like it, then rebuild the resolver library from BSD source (available from a number of places), and install a new shared library. You can convienently rewrite some of the other troublesome features (like wasting time doing a gethostbyaddr on inbound login connections, maybe get rid of all utmp host information) at the same time! How about just having gethostbyname return a hardwired answer like not-me.yourdomain.edu. ? This way you wouldn't have to wait for that pesky DNS to figure out where you are logging in from to timeout when you botch the DNS configuration! What a plus! After all, not all sites require knowing where people log in from. Why should everyone have to put up with these silly delays because a few paranoids out there worry all the time! >extra checking you describe in Sun gethostbyname() is an attempt to use >it as an authentication service. This is WRONG behavior for >gethostbyaddr(). It may make sense to add this type of authentication >to some specific uses (say in rlogind, when checking hosts.equiv). But >it does not make sense in general. > Bull. The DNS system is a distributed database. Are you saying that you don't care how valid the information is as long as it tells you something?? If you can tell someone has misconfigured things or is trying to spoof your system, that's pretty useful info for me. As for using it in only things that require .rhosts type of files, well, I'm sure you'd be rather annoyed when someone breaks into your machine from the Internet and spoofs the PTR information so that when you try and contact the system admin. of the host that connected to you, you get nowhere. Ah, but then you don't care about security! I'm sorry I forgot... If the info is wrong, it shouldn't be shoved into utmp. I can't believe all this garbage blaming the resolver code!!! If you have a problem with the NSS's not doing this, call MERIT and complain. I notice most other people seem to get this right. Don't blame the resolver for doing the right thing. If this REALLY annoys you, why not just relink traceroute with the straight BSD resolver? Sigh... Thanks, Milo PS Usual disclaimers apply...
rickert@mp.cs.niu.edu (Neil Rickert) (01/13/91)
In article <1991Jan13.054040.21009@riacs.edu> medin@cincsac.arc.nasa.gov (Milo S. Medin) writes: > >Bull. The DNS system is a distributed database. Are you saying that you >don't care how valid the information is as long as it tells you something?? >If you can tell someone has misconfigured things or is trying to spoof your >system, that's pretty useful info for me. > I am not saying this. I am saying that when you have a distributed database with widely distributed control, you can NEVER guarantee that the data is valid or consistent. But just because there may be invalid data, that is no reason to break your software so that it can't even read the data. Put your consistency checks in those few packages (rlogind, etc) that need it. And don't assume that even these consistency checks guarantee security. Real security would require rlogind and other such software to limit access to a prescribed set of networks or subnets which are known to be well managed and secure. If this were done the PTR record spoofing would become unimportant. >As for using it in only things that require .rhosts type of files, well, I'm >sure you'd be rather annoyed when someone breaks into your machine from the >Internet and spoofs the PTR information so that when you try and contact >the system admin. of the host that connected to you, you get nowhere. Ah, but If someone spoofs the PTR info, what makes you think the sysadmin would be helpful anyway. Either the whole domain isn't administered, or the admin is involved, if the DNS records are incorrect. If this security checking is done in rlogind, rather than gethostbyaddr() you still can be just as effective in reducing the security exposures. If someone can break in with telnet, they can probably break in with a telephone and a modem. >I can't believe all this garbage blaming the resolver code!!! If you >have a problem with the NSS's not doing this, call MERIT and complain. I notice >most other people seem to get this right. Don't blame the resolver for doing >the right thing. If this REALLY annoys you, why not just relink traceroute >with the straight BSD resolver? Sigh... This subject line started with a complaint that there are PTR records for which the corresponding A-records do not exist. The point is this: It would be possible to set standards requiring that where a PTR record exists the corresping A record must also exist. The net effect will be the removal of many PTR records from the DNS, and this will be a net loss of information. If this removal of PTR records is what you want, you have no reason to complain for your modified gethostbyaddr() is effectively removing these PTR records anyway. You may think your complaint will get you back the info, but at best it will cause the rest of the Internet to also lose the information. If administrators don't want to advertise an A-record for whatever reason, they won't. They place the PTR records there to give some additional identification information, but can quite easily remove them if push comes to shove. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
thorinn@DIKU.DK (Lars Henrik Mathiesen) (01/14/91)
From: medin@nsipo.arc.nasa.gov (Milo S. Medin) rickert@mp.cs.niu.edu (Neil Rickert) writes: > Just because Sun's 'gethostbyaddr()' is broken, there is no reason to >complain about the way domains are set up. > > The public BSD sources do not have this defect. This is not broken, nor is it a defect, and nor is it limited to SUN's. We at Ames came up with this mod to the resolver code after having been burned by internet DNS spoofing. If your resolver doesn't have this capability, your site is open to a lot of security problems. Any system with the original BSD resolver library has this capability: Follow the gethostbyaddr with a gethostbyname and check if the original address appears in the address list. Sun and Ames evidently didn't want to spend the time needed to change the programs needing this (very weak) authentication, and implemented it in gethostbyaddr instead. Berkeley implemented it in the network daemons with the tahoe release (at least Mt. Xinu did in their version; it's 26 lines of boilerplate code in each program). Now Ames are free to decide if they want to live with the consequences of making gethostbyaddr ``safe'', but for Sun it is a clear case of lessened utility: There is now no library routine that will give the name of a host regardless of A records. Since there are programs that make good use of precisely such a routine, users of such programs are entitled to complain about Sun's move. I'm not saying that Sun shouldn't have put in the check, but that it was a bad place to put it. By the way, I think the article that Milo came down so hard on said much the same. -- Lars Mathiesen, DIKU, U of Copenhagen, Denmark [uunet!]mcsun!diku!thorinn Institute of Datalogy -- we're scientists, not engineers. thorinn@diku.dk We turned this bug into Sun, and posted it on comp.bugs.4bsd. Many sites use this since they consider security marginally important. If you don't, that's fine, and more power to you, but don't berate the efforts of a vendor who is concerned with improving the state of security. If you don't like it, then rebuild the resolver library from BSD source (available from a number of places), and install a new shared library. You can convienently rewrite some of the other troublesome features (like wasting time doing a gethostbyaddr on inbound login connections, maybe get rid of all utmp host information) at the same time! How about just having gethostbyname return a hardwired answer like not-me.yourdomain.edu. ? This way you wouldn't have to wait for that pesky DNS to figure out where you are logging in from to timeout when you botch the DNS configuration! What a plus! After all, not all sites require knowing where people log in from. Why should everyone have to put up with these silly delays because a few paranoids out there worry all the time! >extra checking you describe in Sun gethostbyname() is an attempt to use >it as an authentication service. This is WRONG behavior for >gethostbyaddr(). It may make sense to add this type of authentication >to some specific uses (say in rlogind, when checking hosts.equiv). But >it does not make sense in general. > Bull. The DNS system is a distributed database. Are you saying that you don't care how valid the information is as long as it tells you something?? If you can tell someone has misconfigured things or is trying to spoof your system, that's pretty useful info for me. As for using it in only things that require .rhosts type of files, well, I'm sure you'd be rather annoyed when someone breaks into your machine from the Internet and spoofs the PTR information so that when you try and contact the system admin. of the host that connected to you, you get nowhere. Ah, but then you don't care about security! I'm sorry I forgot... If the info is wrong, it shouldn't be shoved into utmp. I can't believe all this garbage blaming the resolver code!!! If you have a problem with the NSS's not doing this, call MERIT and complain. I notice most other people seem to get this right. Don't blame the resolver for doing the right thing. If this REALLY annoys you, why not just relink traceroute with the straight BSD resolver? Sigh... Thanks, Milo PS Usual disclaimers apply...
huntting@csn.org (01/14/91)
7thson@slcs.slb.com (Chris Garrigues) writes: > If a host or gateways has multiple addresses, these addresses SHOULD > have PTR records pointing either to the same name OR to names with CNAME > records pointing to a common name. Wait a sec... Are you advocating the following: glarp.x. in a 128.1.1.1 glarp.x. in a 128.1.2.2 glarp-intf1.x. in cname glarp.x. glarp-intf2.x. in cname glarp.x. 1.1.1.128.in-addr.arpa. in ptr glarp-intf1.x. 2.2.1.128.in-addr.arpa. in ptr glarp-intf2.x. My understanding was that only canonical names should be referenced in RR's. In the above example, the names `glarp-intf[12].x' are not canonical, and so should not be refered to in ptr records (or any other records for that matter). What should gethostbyaddr(128.1.1.1) return in such a case? `glarp-intf1.x' or `glarp.x'? BIND4.8.2 will (I believe) return `glarp-intf1.x'. Is a nameserver supposed to do cname lookups only at the begining of a queary and not bother after it has found data? Is this written down somewhere? Consider a similar case: foo.x. in mx 10 foo.x. in mx 20 mhub.x. mhub.x. in cname glarp.x. Someone at my site recently did this. And hosed themselves pretty good. `Glarp' was supposed to spool mail `foo''s mail when `foo' was down. Insted it was trying to contact `mhub', and was getting confused whilest "talking to itself". All this basically because the resolver was expecting a canonical name and got `mhub'. The machines ruleset 0 was smart enough to deliver mail for `mhub' locally. I suppose we might have been able to solve this by forcing the name `mhub' into the $=w macro in sendmail.cf. Insted we just changed the mx 20 record to point go `glarp' directly. brad huntting@csn.org huntting@colorado.edu << Caps Lock? Caps Lock? We Dont need no Stinking CAPS LOCK! >>
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (01/15/91)
In article <1991Jan13.054040.21009@riacs.edu>, medin@nsipo.arc.nasa.gov (Milo S. Medin) writes: > > We turned this bug into Sun, and posted it on comp.bugs.4bsd. Many sites use > this since they consider security marginally important. If you don't, that's > fine, and more power to you, but don't berate the efforts of a vendor who is > concerned with improving the state of security. If you don't like it, > then rebuild the resolver library from BSD source (available from a > number of places), and install a new shared library.... > As for using it in only things that require .rhosts type of files, well, I'm > sure you'd be rather annoyed when someone breaks into your machine from the > Internet and spoofs the PTR information so that when you try and contact > the system admin. of the host that connected to you, you get nowhere. Ah, but > then you don't care about security! I'm sorry I forgot... If the info is > wrong, it shouldn't be shoved into utmp. .... This is a reasonable reasonse at a large end-user site connected to the Internet and with a healthy concern for security. However, if the extra check is made in the few places that change /etc/*tmp based on gethostbyaddr(), such as rlogind and ftpd, then only the "right" information will be shoved into utmp. For one vendor, my employer, changing gethostbyaddr() to always do the check and choke on glitches is a bad idea. Making the reverse lookup in one place would break too many things to justify saving the time required to make and maintain the same check in about 5 places. It's reasonable to expect large Internet sites like NASA Ames to get their DNS databases right. It would be silly to expect, not to mention require, as much on smaller nets not connected to anything. There is also a better way to implement the check. Let "safe_gethostbyaddr()" return either the obvious struct hostent or a synthetic one with a "hostname" that is the ASCII string in the familiar dotted notation, representing the target IP address. If you do this, you need not care if the other end of the circuit has their DNS together or is an evil spoofer. Innocents will find that traceroute and even rlogin work, while malefactors will be disappointed. Vernon Schryver, Silicon Graphics, vjs@sgi.com