From Firewalls-Owner Sun Oct 4 20:55:40 1992 Return-Path: brent@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09421; Sun, 4 Oct 92 20:55:40 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09405; Sun, 4 Oct 92 20:55:07 PDT Message-Id: <9210050355.AA09405@mycroft.GreatCircle.COM> To: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Cc: firewalls@GreatCircle.COM Subject: Reverse and double-reverse IP address lookups as service prerequisites In-Reply-To: Your message of Sun, 4 Oct 92 18:27:37 -0400 Reply-To: Brent@GreatCircle.COM Date: Sun, 04 Oct 92 20:55:06 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) writes: # Inside of Digital, we configure our FTP proxy to reject all # hosts that don't have a reverse address mapping. This way, if a # subnet isn't set up right, they don't get to use the FTP proxy. It # is amazing how quickly people will fix things if you give them a # reason to. A variety of implementations of a number of services, particularly SMTP and FTP servers, do this. I find it mildly annoying, but not really a problem. One sticky issue is: what if I desire to hide the internal naming structure of my network? I think this is a valid goal, given that project information can sometimes be inferred simply by knowing what the machines are named, and that any such handle you get is something that "the bad guys" can for "social engineering" their way past an unwitting receptionist or security staff. I resolve this by using a wildcard PTR record in my DNS data so that all but hosts with explicit PTR records (the gateway/firewall hosts, for instance) return "unknown" (actually "unknown.domain.net", for whatever the appropriate "domain.net" is) when you do an address-to-name translation through DNS. This satisfies the service provider's desire to know who they're talking to (they know what domain it is, at least), and satisfies my desire to to keep my internal network structure and naming private. The thing I _really_ think is a problem is so-called "double reverse" lookups. In a double reverse lookup, after you do the address-to-name translation to find the name of the host that's calling you, you then do a name-to-address translation on that name to see if the address you get back matches the address that's calling you. If the two addresses don't match, you disallow the connection. I don't know what that's really supposed to provide in the way of security, but it sure screws up systems which hide internal hostnames as descirbed above, and systems where machines with multiple network interfaces appear to be separate machines in the DNS databases (I know this _shouldn't_ be necessary, but it often _is_ necessary to work around routing and configuration limitations in today's software). If you look up "unknown.MyDomain.COM", which IP address from a hidden internal machine should I give you? And what if you look up 143.191.19.66 and get back "nb.MyDomain.COM", and then look up "nb.MyDomain.COM" and get back 143.191.20.66 (because that's the _other_ interface on nb.MyDomain.COM)? What we've got here is a dilemna: on the one hand, we've got the desire of the service provider to know exactly who they're talking to. On the other hand, we've got the desire of the service user to hide their internal network naming and structure. Whose desire should win out? In the long run, I think double-reverse is going to go away. I don't see that it really buys you any security as a service provider; it just trips you up over everybody else's buggy DNS databases and security measures. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Oct 5 00:14:52 1992 Return-Path: Firewalls-Owner@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09635; Mon, 5 Oct 92 00:14:52 PDT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA09629; Mon, 5 Oct 92 00:14:47 PDT Message-Id: <9210050714.AA09629@mycroft.GreatCircle.COM> Received: by inet; Mon Oct 5 03:12 EDT 1992 From: smb@ulysses.att.com To: Brent@GreatCircle.COM Cc: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites Date: Mon, 05 Oct 92 03:12:19 EDT Sender: Firewalls-Owner@GreatCircle.COM The thing I _really_ think is a problem is so-called "double reverse" lookups. In a double reverse lookup, after you do the address-to-name translation to find the name of the host that's calling you, you then do a name-to-address translation on that name to see if the address you get back matches the address that's calling you. If the two addresses don't match, you disallow the connection. I don't know what that's really supposed to provide in the way of security, but it sure screws up systems which hide internal hostnames as descirbed above, and systems where machines with multiple network interfaces appear to be separate machines in the DNS databases (I know this _shouldn't_ be necessary, but it often _is_ necessary to work around routing and configuration limitations in today's software). It's very necessary. Since the forward and reverse trees are entirely separate, if I control a reverse tree for my address space -- either legitimately or because I've subverted a machine -- I can change the reverse mapping to name a machine I know you trust. The multiple interface case isn't a problem. Here's how I set things up. The real name of the machine maps to multiple addresses. If I need more than one, I'll have additional names that map to each individual address. The inverse map generally maps back to the major name; since the code checks the entire list of addresses, it's not a problem. Ultimately, that whole notion may go away, but that won't happen until a real (i.e., cryptographic) authentication system is deployed. From Firewalls-Owner Mon Oct 5 07:00:21 1992 Return-Path: Firewalls-Owner@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10313; Mon, 5 Oct 92 07:00:21 PDT Received: from decuac.DEC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA10305; Mon, 5 Oct 92 07:00:03 PDT Received: from hussar.dco.dec.com by decuac.DEC.COM (5.65/Ultrix-fma) id AA28541; Mon, 5 Oct 92 10:00:13 -0400 XXX Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); id AA01527; Mon, 5 Oct 92 09:59:54 -0400 Date: Mon, 5 Oct 92 09:59:54 -0400 From: mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) Message-Id: <9210051359.AA01527@hussar.dco.dec.com> To: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites Sender: Firewalls-Owner@GreatCircle.COM >One sticky issue is: what if I desire to hide the internal naming >structure of my network? I think this is a valid goal, given that >project information can sometimes be inferred simply by knowing what >the machines are named, and that any such handle you get is something >that "the bad guys" can for "social engineering" their way past an >unwitting receptionist or security staff. Usually, I like to take the approach that hiding host names is "security through obscurity" and as such should not be respected as improving your situation noticeably. There are just too many ways to get host information - I'd rather try to secure my network than hide it. Consider that many sendmails put Received: by hussar.dco.dec.com (5.57/ULTRIX-fma-071791); kind of crud in messages as they fly by. You need to strip all that out at the firewall, and soon you're finding yourself back in an "arms race". Another way of looking at it is to realize that concern about "social engineering" should be across the board. If you're afraid that I might find a hostname in your network and call your help desk and say "I forgot my password on 'mumble'" you also need to take into account the staff members who will ignorantly give out their address as "joe@mumble.bar.com" -- the information is GOING to leak out. Worry about how to secure mumble.bar.com and make sure that people don't name their machines "top-secret-project.bar.com" and you're better off. mjr. From Firewalls-Owner Mon Oct 5 11:17:10 1992 Return-Path: brent@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11330; Mon, 5 Oct 92 11:17:10 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA11323; Mon, 5 Oct 92 11:17:07 PDT Message-Id: <9210051817.AA11323@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites In-Reply-To: Your message of Mon, 5 Oct 92 09:59:54 -0400 Reply-To: Brent@GreatCircle.COM Date: Mon, 05 Oct 92 11:17:06 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM mjr@decuac.DEC.COM (Marcus J. "Buddy can you spare a clue?" Ranum) writes: # Usually, I like to take the approach that hiding host names is # "security through obscurity" and as such should not be respected as # improving your situation noticeably. I agree that it's security through obscurity, and should not be counted on to protect anything, BUT every little bit helps. Why give folks ammunition, in the way of host names that can be used for "social engineering" or password attempts or anything else? Sure, not making the host names trivially available doesn't solve much, but it's one more piece of the puzzle. Now, all that said, only a couple of the firewalls I've worked on bother to do that. Most of my clients feel the way Marcus does about hiding host names: why bother? My point is, it's possible IF you think it's valuable, and some folks think it's valuable. # There are just too many ways to get host information - I'd # rather try to secure my network than hide it. I was definitely NOT suggesting hiding it rather than securing it. I was suggesting hiding it AFTER you've done your best to secure it; that gives you one more layer (perhaps trivial) that someone has to work their way through to get to you. I don't believe in absolute security; I don't believe that it's possible. I believe that it's a worthy _GOAL_, but I don't have any illusions that I'm going to actually ACHIEVE the goal. Therefore, I do every little thing I can to tighten up security on the firewall systems I build. Some are big things, like setting up packet filtering in the routers. Some are little things, like hiding internal host names. They all matter, to a greater or lesser degree. Hiding host names is way down on my list of what steps are important to take in securing a network, but it IS on the list. Some of my clients, for whatever reason, never get that far down the list, but some do. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Oct 5 12:25:27 1992 Return-Path: Firewalls-Owner@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12107; Mon, 5 Oct 92 12:25:27 PDT Received: from alpha.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12100; Mon, 5 Oct 92 12:25:22 PDT Received: from sentinel.CES.CWRU.Edu by alpha.CES.CWRU.Edu with SMTP (5.64+/ane.07.08.91.01) id AA13982; Mon, 5 Oct 92 15:25:34 -0400 From: Aydin Edguer Message-Id: <9210051925.AA13982@alpha.CES.CWRU.Edu> Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites To: Brent@GreatCircle.COM Date: Mon, 5 Oct 92 15:21:22 EDT In-Reply-To: <9210051817.AA11323@mycroft.GreatCircle.COM>; from "Brent Chapman" at Oct 5, 92 11:17 aX-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM > I agree that it's security through obscurity, and should not be > counted on to protect anything, BUT every little bit helps. Why give > folks ammunition, in the way of host names that can be used for > "social engineering" or password attempts or anything else? Sure, > not making the host names trivially available doesn't solve much, but > it's one more piece of the puzzle. But the point is that if "I" am trying to break into "your" hosts, then "I" don't really care about the hostname, all "I" need is the IP address. Unless you are going to hide your IP addresses, then hiding the hostnames seems rather pointless (except for mail). If you do hide IP addresses then I fully agree that hiding your hostnames is important and useful. The point of doing a "double reverse" name lookup is security/authentication. It helps to prevent spoofing of the nameserver by people forging PTR records in their nameservers. Thus I think that a "double reverse" name lookup is under normal usage [with or without firewall] going to help cut down on "forgeries" more than hiding only the names is going to help. Aydin Edguer From Firewalls-Owner Mon Oct 5 14:15:45 1992 Return-Path: brent@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12995; Mon, 5 Oct 92 14:15:45 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA12986; Mon, 5 Oct 92 14:15:42 PDT Message-Id: <9210052115.AA12986@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites Reply-To: Brent@GreatCircle.COM Date: Mon, 05 Oct 92 14:15:40 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Aydin Edguer writes: # > I agree that it's security through obscurity, and should not be # > counted on to protect anything, BUT every little bit helps. Why give # > folks ammunition, in the way of host names that can be used for # > "social engineering" or password attempts or anything else? Sure, # > not making the host names trivially available doesn't solve much, but # > it's one more piece of the puzzle. # # But the point is that if "I" am trying to break into "your" hosts, then # "I" don't really care about the hostname, all "I" need is the IP address. # Unless you are going to hide your IP addresses, then hiding the hostnames # seems rather pointless (except for mail). If you do hide IP addresses then # I fully agree that hiding your hostnames is important and useful. Some people (including some but not most of my clients) consider host names to be useful information in and of themselves, regardless of what IP address the host maps to. The host names might give outsiders a clue about projects inside the company, they give outsiders more ammunition for their password cracking programs, and they let outsiders appear to be knowledgable about the site if they try to engage in social engineering to get past human security measures (i.e., if somebody who looks like a repair tech shows up at your receptionist's desk and says "I'm here to work on and it's an emergency; they're waiting for me in the machine room", what's your receptionist going to do? # The point of doing a "double reverse" name lookup is security/authentication. # It helps to prevent spoofing of the nameserver by people forging PTR records # in their nameservers. Thus I think that a "double reverse" name lookup is # under normal usage [with or without firewall] going to help cut down on # "forgeries" more than hiding only the names is going to help. I don't think knowing the name that goes with an IP address really tells you any more than the IP address itself, which you've got regardless. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Mon Oct 5 14:40:40 1992 Return-Path: Firewalls-Owner@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13305; Mon, 5 Oct 92 14:40:40 PDT Received: from alpha.CES.CWRU.Edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA13275; Mon, 5 Oct 92 14:40:20 PDT Received: from sentinel.CES.CWRU.Edu by alpha.CES.CWRU.Edu with SMTP (5.64+/ane.07.08.91.01) id AA14553; Mon, 5 Oct 92 17:40:22 -0400 From: Aydin Edguer Message-Id: <9210052140.AA14553@alpha.CES.CWRU.Edu> Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites To: Firewalls@GreatCircle.COM Date: Mon, 5 Oct 92 17:40:13 EDT X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM > (i.e., if somebody who looks like a repair tech shows up at your > receptionist's desk and says "I'm here to work on machine name> and it's an emergency; they're waiting for me in the > machine room", what's your receptionist going to do? [your examples of why to protect hostnames are very good. I guess I would just want to point out that even with no hostnames, you are still at risk from similar attacks] Well, I realize that the "right" answer is not always the "practical" or "realistic" answer but IMHO the receptionist better call in first... or else. First, because the repair tech will not be able to get through the security stops within the building without an escort and secondly because they will not be able to get into the machine room without the presence of a staff member. If physical security is any more lax then hostnames are not going to save you once the intruder gets physical access to one machine. At one company where I consult, you do not get in without an employee accompanying you. Period. Unless you are the fire department and in that case security is already on the scene. Furthermore, how many receptionists really know the names and locations of all computers in the company? If they really do know the names and locations, does the gateway hostname change internally? If not, then the intruder can just use the gateway hostname to get in. > # It helps to prevent spoofing of the nameserver by people forging PTR records > # in their nameservers. Thus I think that a "double reverse" name lookup is > # under normal usage [with or without firewall] going to help cut down on > # "forgeries" more than hiding only the names is going to help. > > I don't think knowing the name that goes with an IP address really > tells you any more than the IP address itself, which you've got regardless. Well, when tracking things down _after_ the fact, you are correct. But for screening I disagree. Many sites are now using FQDN's for configuration purposes to help prevent problems when machines are changed [e.g. contact SMTP.do.main or NNTP.do.main]. Without verifying the PTR lookup with a further A lookup, the PTR lookup can take place on a remote [cracked] system and return a valid FQDN, that will not be detected until much later. Aydin Edguer From Firewalls-Owner Fri Oct 9 16:15:19 1992 Return-Path: Firewalls-Owner@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26535; Fri, 9 Oct 92 16:15:19 PDT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA26265; Fri, 9 Oct 92 15:28:55 PDT Message-Id: <9210092228.AA26265@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites In-Reply-To: Your message of Mon, 05 Oct 92 03:12:19 EDT Date: Fri, 09 Oct 92 15:28:54 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Steve Bellovin writes, in response to one of my earlier postings: # The thing I _really_ think is a problem is so-called "double reverse" # lookups. In a double reverse lookup, after you do the address-to-name # translation to find the name of the host that's calling you, you then # do a name-to-address translation on that name to see if the address # you get back matches the address that's calling you. If the two # addresses don't match, you disallow the connection. # # I don't know what that's really supposed to provide in the way of # security, but it sure screws up systems which hide internal hostnames # as descirbed above, and systems where machines with multiple network # interfaces appear to be separate machines in the DNS databases (I know # this _shouldn't_ be necessary, but it often _is_ necessary to work # around routing and configuration limitations in today's software). # # It's very necessary. Since the forward and reverse trees are entirely # separate, if I control a reverse tree for my address space -- either # legitimately or because I've subverted a machine -- I can change the # reverse mapping to name a machine I know you trust. Ah, but I don't trust anything based on name. All of my packet filters are set up to filter by address, not name. None of the services on my gateway machines (the one that provides the SMTP, FTP, NNTP, and DNS servers that the outside world can see) do any sort of authentication by name (except for NNTP, which I'm not real concerned about anyway; if I was, I could do it by IP address as well). Here's another way to look at the double reverse issue: what does useful information knowing the name, and being sure of the name, get you that knowing simply the IP address (which you can read directly from the packet) doesn't? I contend that you can't trust the names you get from DNS even if you do a double-reverse lookup, so why should services be obnoxious about it and disallow connections if the double-reverse lookup fails? Certainly you should probably log the failed double-reverse lookups, and perhaps you should warn the client, but is it really reasonable to disallow the connection based on information you can't trust anyway? -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Sat Oct 10 08:48:55 1992 Return-Path: Firewalls-Owner@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA28076; Sat, 10 Oct 92 08:48:55 PDT Received: from seas.smu.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA28070; Sat, 10 Oct 92 08:48:40 PDT Received: by seas.smu.edu (/\==/\ Smail3.1.25.1 #25.1) id ; Sat, 10 Oct 92 10:48 EDT Message-Id: From: doug@seas.smu.edu (Doug Davis) Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites To: avalon@coombs.anu.edu.au Date: Sat, 10 Oct 92 10:48:30 EDT Cc: firewalls@GreatCircle.COM In-Reply-To: <9210101240.AA03741@coombs.anu.edu.au>; from "Darren Reed" at Oct 10, 92 10:40 pm X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM > > In this area, I think it is DNS libraries which are a bit on the deficient > side; it would be nice to be able to set the a preference of /etc/hosts or > a DNS server for each lookup AND also know from which the answer came. Ultrix 4.xx provides this thru the svc config file. It allows you to specifiy one of "local", "yp", and "bind" for resolution of distributed "services" databases. Where the databases are one of aliases, auth, group, hosts, netgroup, networks, passwd, protocols, rpc, or services. The local resolution would be the representitive file on the local machine, such as /etc/hosts for the hosts database. doug From Firewalls-Owner Sat Oct 10 05:40:26 1992 Return-Path: Firewalls-Owner@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27873; Sat, 10 Oct 92 05:40:26 PDT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA27865; Sat, 10 Oct 92 05:40:06 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA03741; Sat, 10 Oct 92 22:40:04 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9210101240.AA03741@coombs.anu.edu.au> Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites To: firewalls@GreatCircle.COM Date: Sat, 10 Oct 92 22:40:03 EST In-Reply-To: <9210092228.AA26265@mycroft.GreatCircle.COM>; from "Brent Chapman" at Oct 9, 92 3:28 pmeply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM In some email I received from Brent Chapman, Sie wrote: [...] > Ah, but I don't trust anything based on name. All of my packet > filters are set up to filter by address, not name. None of the > services on my gateway machines (the one that provides the SMTP, FTP, > NNTP, and DNS servers that the outside world can see) do any sort of > authentication by name (except for NNTP, which I'm not real concerned > about anyway; if I was, I could do it by IP address as well). [...] Your lack of trust in DNS replies is well founded, but it may well be useful for you to know who is trying to spoof DNS records if you do an IP#->name lookup (from a DNS server) and get a 'local' machine name which has a different IP# to that which you're doing a lookup on. In this area, I think it is DNS libraries which are a bit on the deficient side; it would be nice to be able to set the a preference of /etc/hosts or a DNS server for each lookup AND also know from which the answer came. Then at least you can depend on local mappings (from /etc/hosts) and start asking questions when you see a clash. Darren. From Firewalls-Owner Sat Oct 10 12:16:08 1992 Return-Path: Firewalls-Owner@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA28293; Sat, 10 Oct 92 12:16:08 PDT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA28287; Sat, 10 Oct 92 12:15:43 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA11656; Sun, 11 Oct 92 05:15:46 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9210101915.AA11656@coombs.anu.edu.au> Subject: Re: DNS lookups To: firewalls@GreatCircle.COM Date: Sun, 11 Oct 92 5:15:45 EST Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM In some email I received from Doug Davis, Sie wrote: > > > In this area, I think it is DNS libraries which are a bit on the deficient > > side; it would be nice to be able to set the a preference of /etc/hosts or > > a DNS server for each lookup AND also know from which the answer came. > > Ultrix 4.xx provides this thru the svc config file. It allows > you to specifiy one of "local", "yp", and "bind" for resolution > of distributed "services" databases. Where the databases are one of > aliases, auth, group, hosts, netgroup, networks, passwd, protocols, rpc, > or services. > > The local resolution would be the representitive file on the local > machine, such as /etc/hosts for the hosts database. The Ultrix style configuration is also available if you replace your native resolve library with resolv+ (by Bill Wisner) which lets you choose the order of lookup. However, even with either the Ultrix approach or resolv+, what is really needed is to be able to look "local" and then (optionally) continue to do a "bind" lookup OR the other way around. Even still, its only worth doing a lookup on an IP# if it hasn't been faked, which is where the using packet screens/filters come into things by removing (obviously) bogus packets. Although mobile hosts could cause some interesting problems in the future for firewalls. Darren. From Firewalls-Owner Sun Oct 11 04:25:19 1992 Return-Path: Firewalls-Owner@GreatCircle.COM Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA00550; Sun, 11 Oct 92 04:25:19 PDT Received: from eurogate.bnr.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-920924) id AA00544; Sun, 11 Oct 92 04:25:12 PDT Received: from bnr.co.uk by eurogate.bnr.co.uk with SMTP (PP) id <17832-0@eurogate.bnr.co.uk>; Sun, 11 Oct 1992 12:24:45 +0100 Received: from bnr.co.uk by innergate.bnr.co.uk with SMTP (PP) id <01518-0@innergate.bnr.co.uk>; Sun, 11 Oct 1992 12:24:40 +0100 To: avalon@coombs.anu.edu.au Cc: firewalls@GreatCircle.COM Subject: Re: Reverse and double-reverse IP address lookups as service prerequisites In-Reply-To: Message from Darren Reed on Sat, 10 Oct 92 22:40:03 -0500. Organisation: BNR Europe, HARLOW, Essex CM17 9NA, GB Phone: +44 279 402423 Date: Sun, 11 Oct 92 12:24:37 +0100 Message-Id: <14297.718802677@alder2.bnr.co.uk> From: Andrew Macpherson (Postmaster) Sender: Firewalls-Owner@GreatCircle.COM Darren Reed wrote: | Your lack of trust in DNS replies is well founded, but it may well be | useful for you to know who is trying to spoof DNS records if you do an | IP#->name lookup (from a DNS server) and get a 'local' machine name | which has a different IP# to that which you're doing a lookup on. | | In this area, I think it is DNS libraries which are a bit on the deficient | side; it would be nice to be able to set the a preference of /etc/hosts or | a DNS server for each lookup AND also know from which the answer came. | | Then at least you can depend on local mappings (from /etc/hosts) and start | asking questions when you see a clash. On a simmilar vein, I've a (yet another) version of libresolv which allows one to chose any order of `/etc/hosts' `DNS-internal' `DNS-global' and `NIS' which works well for `gethostby...' but has slight problems for direct res_ calls (you get whichever last succeeded of `DNS-(in|ex)ternal' which is usually appropriate, but...) This lives in libc on the gateway to which my users log on to access the Internet. It doesn't address the `where did I get this info from?' question, but could easily --- I havn't felt the need yet. If there is sufficient interest I could make a file available for FTP (sufficient > 4) From Firewalls-Owner Tue Dec 1 10:13:36 1992 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12057; Tue, 1 Dec 92 10:13:36 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12048; Tue, 1 Dec 92 10:13:31 PST Message-Id: <9212011813.AA12048@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: what shall thy firewall hardware be? In-Reply-To: Your message of Tue, 1 Dec 92 10:47:07 -0600 Date: Tue, 01 Dec 92 10:13:31 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk stan@tta.com (Stan Hanks) writes # All of the above restrictions are sort of a minimum set, near as I can tell. # There are some other things I like to do as well. Probably under the aegis # of "increased paranoia" although the clients say it's because there are # serious financial risks involved in connectivity. Sure; I hadn't intended to reveal _everything_ in my bag of tricks... :-) # For starters, I perfer to have a seperate network number for the DMZ than the # internal network, and have proxy TELNET and FTP agents on the DMZ host so that # internal network addresses never leak past the exterior DMZ router. I like to use a separate network number for the DMZ, but for another reason. If the DMZ has a different network number than the internal network, then the interior router (between the DMZ and the internal network) can filter out any inbound packet which appears to have an internal source address and any outbound packet which appears to have an internal destination address, because such packets would have to be either spoofs or misrouted. As we've discussed here before, ad nauseum, I don't like proxy FTP/TELNET for a lot of reasons, mostly having to do with availability of clients for heterogeneous internal networks. # I also like to have an MX for *.domain on the DMZ host, to keep station # names and sub-domains from leaking out as well. You'd be surprised how # many people leave useful info laying about in their naming conventions... # And mail header re-writing as well, so that only gateway.domain shows up # on outgoing headers... Absolutely agreed. I've even gone so far on a number of firewalls that I've built to have the DNS server on the gateway host lie to the external DNS. It says it's authoritative, but the only data it has is that relating to machines that the outside world can reach, and a wildcard PTR record to resolve all external lookups of internal addresses to "unknown.whoever.com". The DNS _client_ software on the gateway is set up (via resolv.conf on a UNIX box) to use an _internal_ DNS server, so that inbound mail forwarding and such works. The internal DNS server has all the "real" data, and is configured to forward requests for other data to the gateway server, which proxies the question to the outside world, then relays the answer back to the internal server. So, when a client on the gateway asks a question, it asks the internal server. If the question is about an internal host, the internal server knows the answer. If it's about an external host, the internal server forwards the query to the gateway server, which obtains the answer and passes it back to the internal server, which then hands it to the gateway client. Internal clients get all their answers from the internal server, which either answers directly (because it was a question about an internal host) or forwards the query to the gateway and passes the answer back to the client. External clients get all their answers from the gateway server, which only knows about the things I want the outside world to see. # If I get maximally paranoid, I tend to use a DMZ host that has two network # interfaces. In this configuration you have the exterior router connected to # one interface and the interior router connected to the other. You have to # run routed and usually gated on the DMZ host, and now have a superior platform # from which to do gatewayed filtering, by hi-jacking incoming and outgoing # connection requests and connecting same to the process of your choice, which # while ultimately doing the same thing as expected, may do additional logging # or authentication. I'm far more worried about holes in the UNIX hosts than holes in the routers. # And, things get really interesting when you start having people who # need to remotely access the secure side of the DMZ. How do you meet the # requirements of not having "users" on the DMZ host and still get across? # How do you keep people from picking passwords off as your TELNET session # runs through who knows where? Yeah, this is one of the currently sticky problems, for which I don't have a really good solution. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu Dec 3 08:13:13 1992 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18043; Thu, 3 Dec 92 08:13:13 PST Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18035; Thu, 3 Dec 92 08:13:08 PST Message-Id: <9212031613.AA18035@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: Notes from Firewalls BOF at USENIX LISA Conference In-Reply-To: Your message of Tue, 1 Dec 92 21:14:22 -0500 Date: Thu, 03 Dec 92 08:13:07 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Bob Sutterfield writes: # Does anybody let UDP packets through firewalls? Never let UDP # through firewalls. # # What about DNS and NTP and other such benign stuff? They should all # be handled by a proxy on the firewall or in a DMZ, right? I let DNS through, but only because there's a quirk in BIND that lets me do it with filters that only look at packet destination ports (which is all most of the filtering implementations will let you look at) without exposing any other UDP services. The quirk is that when a BIND server talks to another name server, both ends of the connection use port 53. Thus, I can allow only UDP packets with a destination of port 53 (I don't need to allow all ports >1023 for the return packets, like you must with most TCP services) through the firewall, and DNS servers (or at least BIND-based servers) on both sides of the firewall can talk to each other. I haven't looked at NTP yet; none of the clients I've set up firewalls for have requested it. If it uses a random port for one end of the connection, I don't see any safe way to let NTP traffic through a firewall that only looks at destination addresses; if you do, you'll also end up exposing all RPC-based services, like YP and so forth. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu Dec 3 10:44:25 1992 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18397; Thu, 3 Dec 92 10:44:25 PST Received: from gatekeeper.es.dupont.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA18390; Thu, 3 Dec 92 10:44:17 PST Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991); id AA17765; Thu, 3 Dec 92 13:44:38 -0500 Received: by esds01.es.dupont.com (5.65/ULTRIX-mjr-063191); id AA08250; Thu, 3 Dec 92 13:44:36 -0500 Received: by wind.es.dupont.com (5.57/Ultrix3.0-C) id AA08265; Thu, 3 Dec 92 13:44:26 -0500 Message-Id: <9212031844.AA08265@wind.es.dupont.com> To: Brent Chapman Cc: Firewalls@GreatCircle.COM Subject: Re: Notes from Firewalls BOF at USENIX LISA Conference In-Reply-To: Your message of "Thu, 03 Dec 92 08:13:07 PST." <9212031613.AA18035@mycroft.GreatCircle.COM> Date: Thu, 03 Dec 92 13:44:25 -0500 From: Mike Minnich Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent, NTP is fine as it uses port 123 for both source and destination port. As for BIND, it's not quite as simple as that. One problem I've run into is that your firewall host will typically run named, which implies that UDP socket 23 is bound to it. If you want to point nslookup at another server, you can't if your incoming filters only allow dest port 23 -- nslookup ends up using a source port >1023 which results in the following: > server ns.nic.ddn.mil. Default Server: ns.nic.ddn.mil Address: 192.112.36.4 > set type=ns > . Server: ns.nic.ddn.mil Address: 192.112.36.4 *** Request to ns.nic.ddn.mil timed-out > Mike From Firewalls-Owner Tue Dec 22 14:07:18 1992 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11700; Tue, 22 Dec 92 14:07:18 PST Received: from Sun.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11693; Tue, 22 Dec 92 14:07:11 PST Received: from sun.Eng.Sun.COM by Sun.COM (4.1/SMI-4.1) id AA11986; Tue, 22 Dec 92 14:07:19 PST Received: from sybase.UUCP by sun.Eng.Sun.COM (4.1/SMI-4.1) id AA26780; Tue, 22 Dec 92 14:07:18 PST Received: from ubu.sybgate.sybase.com by sybase.com (4.1/SMI-4.1/SybH3.0) id AA00619; Tue, 22 Dec 92 11:56:54 PST Received: from localhost by ubu.sybgate.sybase.com (4.1/SMI-4.1/SybEC3.1) id AA25794; Tue, 22 Dec 92 11:56:52 PST Message-Id: <9212221956.AA25794@ubu.sybgate.sybase.com> To: avalon@coombs.anu.edu.au Cc: firewalls@GreatCircle.COM Subject: Re: Obvious (?) problem with allowing DNS.. In-Reply-To: Your message of Wed, 23 Dec 92 01:41:22 -0500. <9212221441.AA23766@coombs.anu.edu.au> Date: Tue, 22 Dec 92 11:56:51 -0800 From: Donald R. Proctor (510/596-3828) Content-Length: 1167 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > It has often been said that when setting up a firewall to allow DNS > packets with both source and dest. of port 53 through. There seems > to be an obvious flaw with this - what is to stop crackers using > this 'hole' ? I don't recall if this was allowed just as far as the > 'DMZ' or all the way through... > Darren The best approach is probably to set up an "internal" DNS domain and an "external" DNS domain. The internal domain servers would talk to internal root servers, and the external domain servers would talk to the "real" root servers. That way you don't need to open up port 53 from the DMZ to the internal network(s). Also, you may not have a need to advertise the name of every host on your network to the outside world. In this case, the "external" DNS server can operate with a very minimal DNS database configuration. Of course, a crackers could still conceivably attack your firewall host using port 53. My philosophy, though, is that your packet filtering should be configured so that the firewall host can be completely com- promised, and still not allow a cracker to access hosts on the internal networks. Don Proctor Sybase, Inc. From Firewalls-Owner Thu Jan 28 17:48:06 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00630; Thu, 28 Jan 93 17:48:06 PST Received: from Spectrum.CMC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA00623; Thu, 28 Jan 93 17:47:59 PST Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA25395; Thu, 28 Jan 93 17:46:31 PST Newsgroups: list.firewalls Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: e-mail behind a firewall Message-Id: <1993Jan29.014617.25357@spectrum.CMC.COM> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA References: <19671.9301290124@nym.ossi.com> Date: Fri, 29 Jan 93 01:46:17 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In article <19671.9301290124@nym.ossi.com> aegl@ossi.com (Tony Luck) writes: [How do we make our machines inside the firewall reachable for email addressed to even if that machine is blocked by the firewall ?] >planning on advertising 3 MX records for each host. machine MX 0 machine machine MX 10 mailgate1 machine MX 20 mailgate2 > >Is this an OK plan? Will it even work!? Works like a charm (this is what we do here). >Has anyone ever ``fixed'' named to give >different answers depending on who is asking the questions? Actually, what you do is you run two different name servers on different hosts. The root nameservers point to the servers with the "outside view" zone. Your internal machines have resolver configurations pointing to the "inside view" server. It is a lot of hassle, though, and should not be necessary. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256 From Firewalls-Owner Sun Jan 31 13:55:36 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07054; Sun, 31 Jan 93 13:55:36 PST Received: from rara.ossi.com ([192.240.4.50]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA07047; Sun, 31 Jan 93 13:55:29 PST Received: from nym.ossi.com ([192.240.2.13]) by rara.ossi.com; Sun, 31 Jan 93 13:55:32 PST From: Tony Luck Date: Sun, 31 Jan 93 13:55:55 PST Message-Id: <7798.9301312155@nym.ossi.com> To: Firewalls@GreatCircle.COM Subject: Re: e-mail behind a firewall Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk This is a public "thank you" for all the responses to my question about setting up MX records in DNS. I think that only one of them was posted to the firewalls list, so here is a summary for anyone else out there in netland who wants to know: My proposed idea for MX records for machines behind a firewall was: MX 10 MX 20 MX 30 Where our filters prevent access to the machine directly from the internet, but connection to the gateways are permitted. This will work (and in fact is what *lots* of people are using already). Several people remined me of the non-desirability of making internal machine names visible: 1) It may be a security problem ("sensitive" information may be embedded in hostnames, or the information may be used for "social engineering" be a bad-guy with a silver tongue to talk their way into places that they shouldn't be). 2) Its a dumb idea for users to embed their hostname in their e-mail address (because then, they'll have a heck of a time telling everyone when they move/rename machines). I agree with you all, but for political reasons we will continue to have the machine name visible in out-going mail headers from certain departments (just don't ask ... if those people want to hang themselves, they can, I'm fed up with the arguments). I did take a look at our current set of machine names, and I don't think we are giving anything away (but if a psychiatrist gets hold of them and does some analysis, we may get a visit from some men wearing white coats offering to let us wear some of their "special" jackets :-) Finally I asked if anyone knew of a modified name server that would provide different answers depending on who was asking. Everyone who replied to this part of my question advised me to just run the internal and external name servers on different machines. -Tony Luck From Firewalls-Owner Thu Feb 11 09:50:20 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22228; Thu, 11 Feb 93 09:50:20 GMT Received: from mail.Germany.EU.net by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22219; Thu, 11 Feb 93 01:50:03 PST Received: from sapwdf by mail.Germany.EU.net with UUCP (5.65c/EUnetD-2.2.3.d) via EUnet for greatcircle.com id cF10844; Thu, 11 Feb 1993 10:49:58 +0100 Received: by sap-ag.de (5.52.1/SAP-1.2) id AA29528; Thu, 11 Feb 93 06:04:11 +0100 for greatcircle.com!firewalls Received: from tadpole.Tadpole.COM by mail.Germany.EU.net with SMTP (5.65c/EUnetD-2.2.3.d) via EUnet for sapwdf id cA03876; Thu, 11 Feb 1993 05:33:05 +0100 Received: from ono-sendai (ono-sendai.tadtec.co.uk) by tadpole.tadpole.com (4.1/SMI-4.1) id AA24115; Wed, 10 Feb 93 22:33:24 CST Received: by ono-sendai (4.1/SPARCbook_POP) id AA07487; Wed, 10 Feb 93 22:33:33 CST Date: Wed, 10 Feb 93 22:33:33 CST From: jim@tadpole.com (Jim Thompson) Message-Id: <9302110433.AA07487@ono-sendai> To: firewalls-digest@sap-ag.de, wohler@sap-ag.de Subject: Re: firewalls and dns Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Since the second nameserver is supposed to be geographicly diverse from the first, many people make arrangements with some other organization (typically their IP provider) to supply a secondary server for their zone(s). Jim From Firewalls-Owner Thu Feb 11 16:21:44 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22937; Thu, 11 Feb 93 16:21:44 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA22930; Thu, 11 Feb 93 08:21:20 PST Received: from alias by yonge.csri.toronto.edu with UUCP id <14489>; Thu, 11 Feb 1993 11:21:34 -0500eceived: from dino.alias.com by barney.alias.com with SMTP id AA02023 (5.65a/IDA-1.4.2 for wohler@sap-ag.de); Thu, 11 Feb 93 10:38:37 -0500 Received: by dino.alias.com id AA07464 (5.65a/IDA-1.4.2 for firewalls@greatcircle.com); Thu, 11 Feb 93 10:38:37 -0500 From: chk@alias.com (C. Harald Koch) Message-Id: <9302111538.AA07464@dino.alias.com> Subject: Re: firewalls and dns To: wohler@sap-ag.de Date: Thu, 11 Feb 1993 10:38:35 -0500 Cc: firewalls@GreatCircle.COM In-Reply-To: <9302110226.AA24234@sap-ag.de> from "Bill Wohler" at Feb 10, 93 09:23:55 pm X-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1006 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > dns requires that each domain have two name servers. if my firewall > only allows one host in my network (and domain as well) to be accessed, > where does this second name server come from? Your second DNS server shold be at some other friendly site out there, or your network provider. It's strongly encouraged that your primary nameservers are on different networks in the Internet, so that even if your entire net goes down, nameservice for you still works. Many European sites have this problem; 90% of the time you get "Authoritative host unknown" errors when trying to contact them, and then suddenly their network comes back and everything works. This is not good... -- Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON action, there is an equal | chk@alias.com (work-related mail) and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address) program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet) From Firewalls-Owner Thu Feb 11 17:36:11 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23190; Thu, 11 Feb 93 17:36:11 GMT Received: from sayshell.umd.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23182; Thu, 11 Feb 93 09:35:51 PST Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0) id AA03115; Thu, 11 Feb 93 12:35:44 -0500 Message-Id: <9302111735.AA03115@sayshell.umd.edu> To: chk@alias.com (C. Harald Koch) Cc: wohler@sap-ag.de, firewalls@GreatCircle.COM From: "Louis A. Mamakos" Subject: Re: firewalls and dns In-Reply-To: Your message of "Thu, 11 Feb 1993 10:38:35 EST." <9302111538.AA07464@dino.alias.com> Date: Thu, 11 Feb 1993 12:35:43 -0500 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > > dns requires that each domain have two name servers. if my firewall > > only allows one host in my network (and domain as well) to be accessed, > > where does this second name server come from? Actually, there is nothing in the DNS protocol which requires multiple servers; its just that the system is much more robust with multiple servers. Also note that the number of servers required per zone is more a policy issue of the parent zone that your subdomain is being registered in. > Your second DNS server shold be at some other friendly site out there, or > your network provider. It's strongly encouraged that your primary > nameservers are on different networks in the Internet, so that even if your > entire net goes down, nameservice for you still works. While its helpful to have a DNS server at another site, strictly speaking, its not necessary. If you network is unreachable, what good does it to be able to look up DNS info when no one can contact any of your hosts? (That's assuming that all your hosts are all in one place). If your network is multi-site, then multiple-sited servers become more important. > Many European sites have this problem; 90% of the time you get > "Authoritative host unknown" errors when trying to contact them, and then > suddenly their network comes back and everything works. This is not good... This means that YOUR software is broken, not the DNS or the configuration of the DNS servers. You should not be getting "Authoritative host unknown" errors, since you can't reach a server! I don't experience these problems. Only the authoriative servers for a zone can return a Non-existant Domain error. Your software should return a soft error if it doesn't get a reply from the server, which in the case of mail, should mean that the operation will be retried later on. Louis A. Mamakos University of Maryland, College Park From Firewalls-Owner Thu Feb 11 18:56:46 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23485; Thu, 11 Feb 93 18:56:46 GMT Received: from cs.huji.ac.il by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23478; Thu, 11 Feb 93 10:56:35 PST Received: from shingml.cs.huji.ac.il by cs.huji.ac.il with SMTP id AA01223 (5.65b/HUJI 4.27 for firewalls@greatcircle.com); Thu, 11 Feb 93 20:57:37 +0200 Received: from shuldig.cs.huji.ac.il by shingml.cs.huji.ac.il with SMTP id AA00796 (5.65b/HUJI 4.1 for louie@ni.umd.edu); Thu, 11 Feb 93 20:57:54 +0200 Received: from localhost by shuldig.cs.huji.ac.il with SMTP id AA27933 (5.65c/HUJI 4.1 for firewalls@greatcircle.com); Thu, 11 Feb 1993 20:57:52 +0200 Message-Id: <199302111857.AA27933@shuldig.cs.huji.ac.il> To: "Louis A. Mamakos" Cc: firewalls@GreatCircle.COM Subject: Re: firewalls and dns In-Reply-To: Your message of Thu, 11 Feb 1993 12:35:43 -0500 . <9302111735.AA03115@sayshell.umd.edu> From: Amos Shapira Date: Thu, 11 Feb 1993 20:57:45 +0200 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In message <9302111735.AA03115@sayshell.umd.edu> you write: | If you network is unreachable, what good |does it to be able to look up DNS info when no one can contact any of |your hosts? Mail Xchangers for one example. Validating names for another (e.g. I dunno how sendmail does it, but it might be able to determine the address is wrong and return it to the sender without having to wait for the net to come up). I guess you can find many other examples. |Only the authoriative servers for a zone can return a Non-existant |Domain error. Aren't secondary servers also defined "authoritative"? Does the above sentence invalidates my examples? I think not, but it's a long time since I wrote DNS code... Cheers, --Amos Shapira CS System Group, Hebrew University, Jerusalem, Israel amoss@cs.huji.ac.il From Firewalls-Owner Thu Feb 11 20:38:44 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23881; Thu, 11 Feb 93 20:38:44 GMT Received: from sayshell.umd.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23874; Thu, 11 Feb 93 12:38:37 PST Received: from localhost by sayshell.umd.edu (NX5.67c/NeXT-1.0) id AA03793; Thu, 11 Feb 93 15:38:54 -0500 Message-Id: <9302112038.AA03793@sayshell.umd.edu> To: Amos Shapira Cc: firewalls@GreatCircle.COM From: "Louis A. Mamakos" Subject: Re: firewalls and dns In-Reply-To: Your message of "Thu, 11 Feb 1993 20:57:45 +0200." <199302111857.AA27933@shuldig.cs.huji.ac.il> Date: Thu, 11 Feb 1993 15:38:54 -0500 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > Mail Xchangers for one example. Validating names for another (e.g. I dunno > how sendmail does it, but it might be able to determine the address is wrong > and return it to the sender without having to wait for the net to come up). > > I guess you can find many other examples. I did qualify my comments with "if all your hosts are in one place".. > |Only the authoriative servers for a zone can return a Non-existant > |Domain error. > > Aren't secondary servers also defined "authoritative"? Does the above sentenc e > invalidates my examples? I think not, but it's a long time since I wrote > DNS code... Primary and secondary only reflect the mechanism used to load the zone data into the authoritative server. They are both equally authoritative. If a secondary server (which loads the zone by doing a zone transfer over the internet) is unable to load the zone, it should respond with "Server Error" rather than "Nonexistant Domain"; that is, it should still be treated as a temporary failure. Louis A. Mamakos University of Maryland, College Park From Firewalls-Owner Tue Feb 16 23:01:43 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11546; Tue, 16 Feb 93 23:01:43 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA11533; Tue, 16 Feb 93 15:01:09 PST Message-Id: <9302162301.AA11533@mycroft.GreatCircle.COM> To: Tony Luck Cc: Firewalls@GreatCircle.COM Subject: Re: e-mail behind a firewall In-Reply-To: Your message of Thu, 28 Jan 93 17:24:29 PST Date: Tue, 16 Feb 93 15:01:07 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # We've almost got our internet connection ... but the question of how to # make e-mail work is puzzling some of us. # # We are using filters in a router to block undesirable packets from reaching # our local net from the big bad world. Most of our systems are Sun4's of # various vintages mostly running SunOS 4.1.2. # # My question is on how to set up DNS. Currently we don't care if the outside # world can see our local hostnames ... in fact some parts of the company seem # to think that it is a neat idea for their workstation name to appear on e-mail # headers ... this means that we have to support incoming mail with addresses # like: # # # If we ran separate name servers for internal and external consumption, we # could support this by advertising MX records on the internet for all local # machines pointing them at our two mail servers ... while internally the # MX records for each host would point at themselves. # # But, we don't think that we want separate name servers. So currently we are # planning on advertising 3 MX records for each host. The highest priority # will point to itself, the next two point to each of the mail gateways. Thus # from inside the firewall, people will choose the first MX record and deliver # directly. From outside, machines will first try direct delivery and get # bounced by the filter in the router with ICMP_UNREACHABLE ... and so they # should fall back to one of the other MX records and deliver to one of our # gateways. # # Is this an OK plan? Will it even work!? Should we really go for different # internal and external name servers? Has anyone ever ``fixed'' named to give # different answers depending on who is asking the questions? # # -Tony Luck Did you ever get an answer to this? Basicly, yes, it will work. I've got a couple of sites that are set up that way. The biggest thing you have to be careful of is that some versions of Sendmail (particularly on Suns, unless you've installed Sun patch 100377) are buggy, and don't reliably recognize themselves in a list of MX records for an internal host. If you're running such a broken Sendmail on your gateway, and the internal host happens to be down, the gateway will happily try the next host in the list, which is itself. What it _should_ do is notice that the next-best-host is itself, and simply hold on to the message. What it _will_ do is open an SMTP connection to itself, which trips the "I refuse to talk to myself" or "hostname configuration error" trap (depending on which version of Sendmail you have), and bounces the message. Setting up multiple DNS servers is not difficult. You set up the gateway machine to have a DNS server that only knows what you want the outside world to know. You set up another DNS server on an internal machine that knows about all your hosts and forwards non-local queries to the gateway DNS server (via a "forwarders" line in the /etc/named.boot file). You rig all DNS clients (via their /etc/resolv.conf files), PARTICULARLY including those on the gateway host, to talk to the internal server. If a client (even on the gateway) asks a question about an internal machine, it gets the answer from the internal server. If a client (internal or gateway) asks about an external machine, the internal server forwards the query to the gateway server, then forwards the response back to the client. If somebody out on the Internet asks something, however, they can only get back what the gateway server knows (which isn't much). -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Fri Feb 19 02:37:51 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21558; Fri, 19 Feb 93 02:37:51 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA21549; Thu, 18 Feb 93 18:37:18 PST Message-Id: <9302190237.AA21549@mycroft.GreatCircle.COM> To: gjkriger@gjk.OCUnix.on.ca (George J. Kriger) Cc: Firewalls@GreatCircle.COM Subject: Re: e-mail behind a firewall In-Reply-To: Your message of Thu, 18 Feb 1993 07:23:49 -0500 Date: Thu, 18 Feb 93 18:37:16 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk gjkriger@gjk.OCUnix.on.ca (George J. Kriger) writes: # brent@GreatCircle.COM wrote: # > Setting up multiple DNS servers is not difficult. You set up the # > gateway machine to have a DNS server that only knows what you want the # > outside world to know. You set up another DNS server on an internal # > machine that knows about all your hosts and forwards non-local queries # > to the gateway DNS server (via a "forwarders" line in the # > /etc/named.boot file). You rig all DNS clients (via their # > /etc/resolv.conf files), PARTICULARLY including those on the gateway # > host, to talk to the internal server. If a client (even on the # > gateway) asks a question about an internal machine, it gets the answer # > from the internal server. If a client (internal or gateway) asks # > about an external machine, the internal server forwards the query to # > the gateway server, then forwards the response back to the client. If # > somebody out on the Internet asks something, however, they can only # > get back what the gateway server knows (which isn't much). # # - Will this work if the gateway server is a dual homed host configured # not to forward packets (IPFORWARDING=-1) [I can't see why not, but I # thought I'd check]. It should. The packets are going to and from the in.named server on the gateway, not through the gateway as a router. The gateway gets a request from internal host X, and sends out a request from itself to external host Y; it takes the answer it gets back from external host Y, and sends it as an answer from itself back to internal host X. Automated plagarism... :-) # - I like the setup above, but suppose that I don't have the resources # to set up the internal DNS server immediately. Can I set things up so # that internal hosts can get/send mail from/to the gateway, and still # not reveal the internal hosts when the gateway is queried from the # Internet ? Not as far as I know. I'm unaware of any DNS server that will tell different things to different machines, though it's certainly something folks have talked about and wished for repeatedly. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Fri Feb 19 15:49:56 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23682; Fri, 19 Feb 93 15:49:56 GMT Received: from yonge.csri.toronto.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA23675; Fri, 19 Feb 93 07:49:31 PST Received: from alias by yonge.csri.toronto.edu with UUCP id <14466>; Fri, 19 Feb 1993 10:49:35 -0500eceived: from dino.alias.com by barney.alias.com with SMTP id AA16500 (5.65a/IDA-1.4.2 for gjkriger@gjk.OCUnix.on.ca); Fri, 19 Feb 93 10:37:38 -0500 Received: by dino.alias.com id AA03447 (5.65a/IDA-1.4.2 for Firewalls@GreatCircle.COM); Fri, 19 Feb 93 10:37:36 -0500 From: chk@alias.com (C. Harald Koch) Message-Id: <9302191537.AA03447@dino.alias.com> Subject: Re: e-mail behind a firewall To: gjkriger@gjk.OCUnix.on.ca (George J. Kriger) Date: Fri, 19 Feb 1993 10:37:34 -0500 Cc: Firewalls@GreatCircle.COM In-Reply-To: <9302190715.AA28908@gjk.OCUnix.on.ca> from "George J. Kriger" at Feb 19, 93 07:15:39 am-Mailer: ELM [version 2.4 PL8] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 952 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I only have enough resources for now to run one DNS server and that's on I'm sorry, but I have to protest this comment... If there are so few hosts in your organization, a DNS server takes almost no disk/memory/CPU time; surely you can install more than one? I have six networks here, each with from 5 to 40 machines. Each network has two DNS servers on it. This is for redundancy; if our routers go down, the networks still have DNS, so that hostname lookups still succeed. Unless you're providing name service for thousands of hosts, you should be able to run a DNS server on every machine and still not "eat resources"... -- Main's Law: For every | C. Harald Koch Alias Research, Inc. Toronto, ON action, there is an equal | chk@alias.com (work-related mail) and opposite goverment | chk@gpu.utcs.utoronto.ca (permanent address) program. | VE3TLA@VE3OY.#SCON.ON.CA.NA (AMPRNet) From Firewalls-Owner Sat Feb 20 02:43:00 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27066; Sat, 20 Feb 93 02:43:00 GMT Received: from rain.psg.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA27059; Fri, 19 Feb 93 18:42:54 PST Received: by rain.psg.com (/\==/\ Smail3.1.25.1 #25.4) id ; Fri, 19 Feb 93 18:42 PST Message-Id: From: randy@psg.com (Randy Bush) Subject: Re: e-mail behind a firewall To: gjkriger@gjk.OCUnix.on.ca (George J. Kriger) Date: Fri, 19 Feb 1993 18:42:41 -0800 (PST) Cc: Firewalls@GreatCircle.COM In-Reply-To: <9302190715.AA28908@gjk.OCUnix.on.ca> from "George J. Kriger" at Feb 19, 93 07:15:39 amime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 501 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > I only have enough resources for now to run one DNS server and that's on > the gateway. Behind the gateway, there will be < 6 hosts that can reach the > gateway, a subset of the hosts on the Ethernet. A 2nd server should > arrive ~May/June (famous last words :-) > > I want to minimize the info given out to the external world, how can I do > this ?? You're gonna puke. What we do here in RAINet is to MX the hosts behind the firewall sites, and use an /etc/hosts file for internal hosts. From Firewalls-Owner Mon Feb 22 06:30:16 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09736; Mon, 22 Feb 93 06:30:16 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09725; Sun, 21 Feb 93 22:30:04 PST Message-Id: <9302220630.AA09725@mycroft.GreatCircle.COM> To: gjkriger@gjk.OCUnix.on.ca (George J. Kriger) Cc: firewalls@GreatCircle.COM Subject: Re: filtering RIP and DNS In-Reply-To: Your message of Sun, 21 Feb 1993 21:27:51 -0500 Date: Sun, 21 Feb 93 22:30:03 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk gjkriger@gjk.OCUnix.on.ca (George J. Kriger) writes: # I'm using a Cisco router and a multi-homed UNIX-based host with # IPFORWARDING turned off. The host isn't doing any routing. # Does the router have to pass RIP ?? Why ?? If that router is your sole connection to the Internet, then you don't need to run RIP or any other routing protocol on it. Just set up all the internal networks to have a default route that gets them to the perimeter router. # Regarding DNS, I understand that server-to-server proxy queries are made # via UDP with port 53 for both the source and the destination (assuming BIND # is used). But what about server-to-server bulk data transfer via TCP. I # assume that when the host gets such a request, the destination is port 53, but # the source is a "random" port >1023. Similiarly when the host initiates # such the request. Are these assumptions correct ?? Yes, as far as I know. Allowing zone transfers is not that big a problem because they use TCP rather than UDP. You want to block all the random UDP ports, because you don't know where RPC-based services are going to end up in the UDP port range. Fortunately, most of the really troublesome RPC-based services (NFS and YP in particular) are UDP-only on most machines, though there are some TCP versions of NFS starting to appear. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu Feb 25 19:58:32 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24139; Thu, 25 Feb 93 19:58:32 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA24131; Thu, 25 Feb 93 11:58:21 PST Message-Id: <9302251958.AA24131@mycroft.GreatCircle.COM> To: chk@alias.com (C. Harald Koch) Cc: gjkriger@gjk.OCUnix.on.ca (George J. Kriger), Firewalls@GreatCircle.COM Subject: Re: e-mail behind a firewall In-Reply-To: Your message of Fri, 19 Feb 1993 10:37:34 -0500 Date: Thu, 25 Feb 93 11:58:20 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # > I only have enough resources for now to run one DNS server and that's on # # I'm sorry, but I have to protest this comment... # # If there are so few hosts in your organization, a DNS server takes almost # no disk/memory/CPU time; surely you can install more than one? It may be that there's only one UNIX machine at the site, and that the rest are all Macs or PCs. I find that to be a fairly common configuration; a site that's already an established Mac or PC shop will buy one UNIX box to be the gateway and run DNS and so forth. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Fri Feb 26 02:44:56 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25795; Fri, 26 Feb 93 02:44:56 GMT Received: from gate.demon.co.uk by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA25787; Thu, 25 Feb 93 18:44:39 PST Received: from demon.demon.co.uk by gate.demon.co.uk id ad12304; 26 Feb 93 2:43 GMT Received: from cellnet.uucp by demon.demon.co.uk id aa07064; 26 Feb 93 2:41 GMT From: Steve Kennedy Message-Id: <10000.9302260028@marvin.gbnet.org> Subject: Re: e-mail behind a firewall To: greatcircle.com!brent@gbnet.org Date: Fri, 26 Feb 93 0:28:51 GMT Cc: alias.com!chk@gbnet.org, gjk.ocunix.on.ca!gjkriger@gbnet.org, greatcircle.com!Firewalls@gbnet.org In-Reply-To: <9302251958.AA24131@mycroft.GreatCircle.COM>; from "Brent Chapman" at Feb 25, 93 11:58 X-Subliminal-Message: Send large quantities of used bills. X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Brent, > # > I only have enough resources for now to run one DNS server and that's on > # I'm sorry, but I have to protest this comment... > # If there are so few hosts in your organization, a DNS server takes almost > # no disk/memory/CPU time; surely you can install more than one? > > It may be that there's only one UNIX machine at the site, and that the > rest are all Macs or PCs. I find that to be a fairly common > configuration; a site that's already an established Mac or PC shop > will buy one UNIX box to be the gateway and run DNS and so forth. You can always get a PC DNS server (there is a BIND for PC/TCP+, Chameleon, Super-tcp etc ...). Steve -- ___ |_ ___ ___ Tel: +44 (0)71 483 1169 Voice (___ | (___) \ / (___) Data: 483 2454 WorldBlazer T3000 PEP+/v32bis... ___) | (___ \/ (___ Data: 483 2455 Miracom Courier HST/DS+ V32bis/HST Email Snail Mail steve@gbnet.org/steve@gbnet.com [home] Steve Kennedy steve@marvin.demon.co.uk [DIS dialup internet] Flat 2, 43 Howitt Rd steve@cellnet.co.uk [work] London, NW3 4LU From Firewalls-Owner Sun Mar 14 02:22:14 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12275; Sun, 14 Mar 93 02:22:14 GMT Received: from TIS.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12268; Sat, 13 Mar 93 18:22:08 PST Received: by TIS.COM (4.1/SUN-5.64) id AA28805; Sat, 13 Mar 93 21:22:38 EST Date: Sat, 13 Mar 93 21:22:38 EST From: Marcus J Ranum Message-Id: <9303140222.AA28805@TIS.COM> To: FireWalls@GreatCircle.COM, mischler@cubic.com Subject: Re: DNS Client Ports Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk >Should I allow "random" client ports through? What are the security >implications? One implication is that anyone with a tunnelling driver can run IP tunnelled through your firewall using NS packets as the transport layer. Yes, I have code that does this. ;) mjr. From Firewalls-Owner Sun Mar 14 04:12:16 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12451; Sun, 14 Mar 93 04:12:16 GMT Received: from Spectrum.CMC.COM by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA12444; Sat, 13 Mar 93 20:12:09 PST Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA16731; Sat, 13 Mar 93 20:10:15 PST Newsgroups: list.firewalls Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: DNS Client Ports Message-Id: <1993Mar14.041004.16681@spectrum.CMC.COM> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA References: <9303140222.AA28805@TIS.COM> Date: Sun, 14 Mar 93 04:10:04 GMT Apparently-To: firewalls@greatcircle.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Dave Mischler asks: >>Should I allow "random" client ports through? What are the security >>implications? In article <9303140222.AA28805@TIS.COM> mjr@TIS.COM (Marcus J Ranum) writes: > One implication is that anyone with a tunnelling driver can >run IP tunnelled through your firewall using NS packets as the >transport layer. > > Yes, I have code that does this. ;) You need to allow access to port 53 on your DNS server from ANYWHERE unless you want to preclude many normal maintenance and troubleshooting activities. (NSLOOKUP for example). And no, you probably should not allow access to port 53 of other machines inside to cross the firewall. The above is a good example why. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC Network Products / Rockwell Int'l Telephone: +1-805-968-4262 Santa Barbara, CA 93117-3083 TeleFAX: +1-805-968-8256 From Firewalls-Owner Thu Mar 18 17:02:33 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28915; Thu, 18 Mar 93 17:02:33 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28886; Thu, 18 Mar 93 09:01:47 PST Message-Id: <9303181701.AA28886@mycroft.GreatCircle.COM> To: "Scott M. Hinnrichs" Cc: firewalls@GreatCircle.COM Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints In-Reply-To: Your message of Thu, 18 Mar 93 02:35:48 PST Date: Thu, 18 Mar 93 09:01:46 -0800 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # Well, this may not *really* be a firewall problem, but I am getting this # problem building code for my firewall. I haven't lived under a DNS # patched libc.so for while now. I just installed the libresolv.a objs # in libc.so and now I am getting complaints from ld when making source: # # cc -O -DDEBUG dig.c -L`pwd` -lresolv list.o -o dig # ld: Undefined symbol # _dlopen # _dlclose # _dlsym # __mbstowcs_xccs # __mbtowc_xccs # __wcstombs_xccs # __wctomb_xccs # # This must be due to something obvious I am doing wrong. The patched libc.so # is working fine and the binary ld creates works too! But, many makefiles # won't do a build even when using make -k, and it is a real pain... anyone # seen this already?? # # Thanks, Scott In /usr/lib/shlib.etc/Makefile, add a "-ldl" flag to the end of the "ld" command for the "libc.so" target, then rebuild the shared library. That will take care of the first problem. I'll bet the second problem is caused by not renaming "xccs.multibyte." to "xccs.multibyte.o" after using "ar" to unpack "libc_pic.a". There are three files in libc_pic.a that have long filenames, that have to be renamed before the shared library is built. If I recall correctly, the "README" file lists some but not all of them. The three files are "rpc_commondata.", "rpc_dtablesize.", and "xccs.multibyte."; all need to be renamed to end in ".o" instead of just ".". -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu Mar 18 17:08:27 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29019; Thu, 18 Mar 93 17:08:27 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28997; Thu, 18 Mar 93 09:07:58 PST Message-Id: <9303181707.AA28997@mycroft.GreatCircle.COM> To: peterg@murphy.com (Peter Gutmann) Cc: Firewalls@GreatCircle.COM Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints In-Reply-To: Your message of Thu, 18 Mar 93 10:33:36 EST From: Brent Chapman Date: Thu, 18 Mar 93 09:07:57 -0800 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # > cc -O -DDEBUG dig.c -L`pwd` -lresolv list.o -o dig # > ld: Undefined symbol # > _dlopen # > _dlclose # > _dlsym # > __mbstowcs_xccs # > __mbtowc_xccs # > __wcstombs_xccs # > __wctomb_xccs # # You need to add the -ldl (dynamic loading libs) to the cc Doing that makes _that_ cc work, but who wants to add "-ldl" to every cc in every Makefile on their system? Adding "-ldl" to the "ld" step of building the shared library, as I described in my previous message, solves the problem without requiring you to tweak every Makefile on your system. - -Brent - -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 ------- End of Forwarded Message From Firewalls-Owner Thu Mar 18 17:32:13 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29100; Thu, 18 Mar 93 17:32:13 GMT Received: from mail-relay-2.mv.us.adobe.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29087; Thu, 18 Mar 93 09:31:47 PST Received: by mail-relay-2.mv.us.adobe.com; id AA06442; Thu, 18 Mar 93 09:32:08 -0800 Received: by guardi.mv.us.adobe.com; id AA20640; Thu, 18 Mar 93 09:32:05 -0800 Message-Id: <9303181732.AA20640@guardi.mv.us.adobe.com> To: "Scott M. Hinnrichs" Cc: firewalls@GreatCircle.COM Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints In-Reply-To: Your message of "Thu, 18 Mar 93 02:35:48 PST." <9303181035.AA00268@tardis> Date: Thu, 18 Mar 93 09:32:04 PST From: Tim Guarnieri Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Hmm. When you rebuilt libc.so, did you put -ldl on the following line: ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl ^^^^ If you didn't, I can see where this error would occur. Tim BTW: Attached is a "How to modify SunOS to use DNS instead of YP" note that I pulled off the net a while ago. I found it very helpful when rebuilding libc.so. Hope it helps. ----------------- NEW BIND FOR SUNS 2/11/91 ----------------- [Partially taken from the document "Making a libc.so for DNS without NIS" that has been distributed to various SunOS users, and seen on Usenet. Original document by Paul Balyoz (pab@naucse.cse.nau.edu). Updated to include OS4.1.2 information, Hal Pomeranz, 3/3/92. ] This document tells how to install a NEW version of the BIND Name Server resolver routines into the shared C library of a Sparcstation running SunOS 4.1 or greater. The procedure is a bit different when you are trying to install a version of BIND distributed from Berkeley, compared to the (older) resolver library that comes with SunOS. A. Get BIND version 4.8.3 or later. We must fix the Makefile in the resolver directory to do what our sparcstation needs. The whole idea here is to compile the C source to .o files with the -pic option, and not do anything fancy to the .o files before putting them into the new libresolv.a library. Note that we rename your old libresolv.a file, so that it can be recovered if the new one doesn't work! cd Bind4.8.3/res vi Makefile Comment out all sets of lines that look something like: -ld -r -x file.o mv a.out file.o Add to the "CFLAGS" variable the option -pic (so that a global tags entry gets added to each .o file) Fix paths and options in Makefile as needed. make mv /usr/lib/libresolv.a /usr/lib/libresolv.a.orig make install This should have created the new /usr/lib/libresolv.a library. Please also note that the string(3) man-page which comes with SunOS is more complete than the one distributed with BIND! Therefore you should NOT replace it as instructed to by BIND's README instructions. B. Follow the steps below to make a new shared library on your Sun which includes the new resolver library routines in it. 1. Become super user by logging in as root, or first as a normal user and then typing: su 2. Move into the shared-lib area and make a temporary directory: cd /usr/lib/shlib.etc mkdir tmp 3. Move into this new directory, extract the pic (position independent code) object files from libc_pic.a and remove the SYMDEF file. The renaming (mv commands) is done because the "ar" command truncates names to 16 characters. cd tmp ar x ../libc_pic.a rm __.SYMDEF mv rpc_dtablesize. rpc_dtablesize.o mv rpc_commondata. rpc_commondata.o mv xccs.multibyte. xccs.multibyte.o 4. We now need to extract the object files from your new libresolv.a library, making sure not to overwrite two of the Sun objects already in this directory: mv mktemp.o mktemp.o2 # else it gets stomped mv strpbrk.o strpbrk.o2 # else it gets stomped ar x /usr/lib/libresolv.a mv strpbrk.o2 strpbrk.o # we gotta use Sun's. mv mktemp.o2 mktemp.o # we gotta use Sun's. (Any other object files that get overwritten are ok.) [ Alternatively you can extract Sun's original mktemp.o and strpbrk.o files again at this point by typing: ar x ../libc_pic.a mktemp.o strpbrk.o ] 5. Make sure the old host resolver is not still lying around: rm gethostent.o (ignore error "rm: gethostent.o nonexistent" if you see it.) 6. Remove the new resolver's string code because Sun's libraries already includes this, so it would be redundant: rm strcasecmp.o 7. Go back up to the shared library building directory and duplicate the list of object files to use: cd .. cp lorder-sparc lorder-sparc.orig 8. Edit this object file list and make the following modifications if they haven't already been done before to this file: remove: gethostent.o add: gethostnamadr.o sethostent.o res_query.o res_mkquery.o res_send.o res_debug.o res_comp.o res_init.o herror.o strerr.o (the last two are new, which Sun's resolver doesn't use) After deleting gethostent.o, you can use the following patch, or make the changes by hand (in this order): *************** *** 149,154 **** --- 149,164 ---- listen.o getwd.o getnetgrent.o + gethostnamadr.o + herror.o + sethostent.o + res_query.o + res_mkquery.o + res_send.o + res_debug.o + res_comp.o + res_init.o + strerror.o ypxdr.o ttyname.o setbuffer.o 9. The Makefile in shlib.etc for building shared libraries has one problem when you run it as the super user. So edit it and modify the definition of "OBJSORT" to read: OBJSORT=./objsort If you are using SunOS 4.1.2, change the lines (there are two) in the Makefile which read ld -assert pure-text `${OBJSORT} lorder-sparc tmp` to read ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl 10. Now we can finally build the shared library. Type: make libc.so What kind of errors might you get? Here's a couple: a. It blows up on one of the .o files in tmp, saying that the object file is in an inconsistent state. SOLUTION: start over; you did something wrong when you compiled the new libresolv.a in section A, above. Make SURE not to let Makefile "ld" the object files! b. It lists hundreds of error lines about offsets or addresses being wrong in all your resolver .o files. SOLUTION: start over; you needed to specify "-pic" to the C compiler when building the libresolv.a library. 11. If all goes well, you now have a "libc.so.x.y.z" in this directory. Test it out before installing it systemwide! You can do this by pointing your shell's library path variable to the current directory, then trying various networking commands: setenv LD_LIBRARY_PATH `pwd` ping some.host.edu ftp another.host.com telnet someone.else.ca unsetenv LD_LIBRARY_PATH If anything in the library fails, you need to start section B over again. Maybe you forgot to use Sun's versions of mktemp.o and strpbrk.o; things just won't work with BIND's new versions of these files. 12. When you are sure it's working OK, you can install it into the system library directory: cp lib.so.x.y.z /usr/lib chmod 755 /usr/lib/lib.so.x.y.z ldconfig 13. You can prove that you're using the new library now, by watching the output of something like: trace date The lastest BIND resolver is now installed on your system. You can go ahead and compile and install the other BIND tools such as named, nslookup, etc. You do not need to specify the "-lresolv" library when compiling these tools. From Firewalls-Owner Thu Mar 18 19:14:36 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29437; Thu, 18 Mar 93 19:14:36 GMT Received: from tardis ([198.37.128.10]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA29430; Thu, 18 Mar 93 11:14:27 PST Received: by tardis (4.1/netserv-1.0) id AA00528; Thu, 18 Mar 93 11:16:03 PST Date: Thu, 18 Mar 93 11:16:03 PST From: Scott M. Hinnrichs Message-Id: <9303181916.AA00528@tardis> To: smh@netserv.com, ckaul@cs.sandia.gov Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints Cc: firewalls@GreatCircle.COM, len@netsys.com Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Ok, Clint wins ;-) He answered correctly first. I *knew* it was a lame question/answer but *I* didn't know :( My SunSpots article was from '90, and I hadn't done it since then. Thank god I didn't suffer for a couple of months like some of the post'ers. Thanks all!, Scott > From ckaul@cs.sandia.gov Thu Mar 18 05:51:14 1993 > Date: Thu, 18 Mar 93 06:49:32 MST > From: ckaul@cs.sandia.gov (Clint Kaul) > To: smh@netserv.com > Subject: Re: DNS/libresolv/4.1.3/dlopen ld complaints > Content-Length: 697 > > Scott, > > You have stumbled across two common problems. You are probably running > SunOS 4.1.2 or 4.1.3. There are two mods that need to be done: > > 1. In /usr/lib/shlib.etc/Makefile under the libc.so target: > Change: ld -assert pure-text `${OBJSORT} lorder-sparc tmp` > To: ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl > > 2. There is now another file from libc.a which has a forshortened name: > /usr/lib/shlib.etc/tmp% mv xccs.multibyte. xccs.multibyte.o > > Hope this helps, > > Clint Kaul Work: 505-845-7557 or 505-250-5105 (mb) > Sandia National Labs Fax: 505-845-7442 > Department 1421 Home: 505-843-7159 or 505-843-6015 > Albuquerque, NM 87185-5800 Email: ckaul@cs.sandia.gov > From Firewalls-Owner Sun Apr 18 16:12:41 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28459; Sun, 18 Apr 93 16:12:41 GMT Received: from grasp1.univ-lyon1.fr by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28452; Sun, 18 Apr 93 09:12:29 PDT Received: by grasp1.univ-lyon1.fr (5.67a8/IDA-1.5f) via Rocad id AA02530; Sun, 18 Apr 1993 18:13:03 +0200 From: Christophe Wolfhugel Message-Id: <199304181613.AA02530@grasp1.univ-lyon1.fr> Subject: Re: DNS over TCP To: avalon@coombs.anu.edu.au Date: Sun, 18 Apr 1993 18:13:01 +0100 (MEST) Cc: firewalls@GreatCircle.COM In-Reply-To: <9304181538.AA14393@coombs.anu.edu.au> from "Darren Reed" at Apr 19, 93 01:38:03 am X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 599 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Darren Reed said: |so why not ? Are DNS transactions light weight enough to make requiring |TCP an overkill ? What if the TCP connection were kept open during the |life of the namesrver rather than on a per-request basis ? TCP connections are a pain for the DNS. IBM's stupid netstat uses one such... I just can't imagine all the datagrams and time wasted in TCP handshaking particularly true on slow lines ! Keeping TCP sockets open ? I can't imagine to have 200 open just for the pleasure. Keep it on UDP ! -- Christophe Wolfhugel | Email: Christophe.Wolfhugel@grasp.insa-lyon.fr From Firewalls-Owner Sun Apr 18 16:53:08 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28529; Sun, 18 Apr 93 16:53:08 GMT Received: from coombs.anu.edu.au by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA28522; Sun, 18 Apr 93 09:52:54 PDT Received: by coombs.anu.edu.au (5.61/1.0) id AA16561; Mon, 19 Apr 93 02:53:54 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9304181653.AA16561@coombs.anu.edu.au> Subject: Re: DNS over TCP To: louie@NI.umd.edu (Louis A. Mamakos) Date: Mon, 19 Apr 93 2:53:53 EST Cc: firewalls@GreatCircle.COM In-Reply-To: <9304181639.AA05598@sayshell.umd.edu>; from "Louis A. Mamakos" at Apr 18, 93 12:39 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk In some email I received from Louis A. Mamakos, Sie wrote: [...] > > so why not ? Are DNS transactions light weight enough to make requiring > > TCP an overkill ? What if the TCP connection were kept open during the > > life of the namesrver rather than on a per-request basis ? > > > > It would greatly increase the amount of traffic and time to perform a > simple query, as well as increase the resource useage on both the > "client" machine and the name server. It is impractical to just keep > a connection open to "the" name server. > > Some root name servers, for instance, will refuse to accept TCP > connections for queries because of the additional overhead. For > example, the root name server which we run at the University of > Maryland processes on the order of 5 queries per second, averaged over > a day. Okay, what I was getting at here was people often have a normal host in the 'DMZ' which has less restrictions than the rest of the protected network and often is used to relay news/email (and maybe do proxy ftp, telnet, etc) which could be setup to use a TCP connection to the remote nameserver that it looks up to while allowing UDP from internal machines. To keep this open for the life of the nameserver as the forwardding point isn't going to cost much more and could be setup by special arrangement if the upstream server normally disallows TCP connections. It is also possible that a TCP DNS tree would be more 'secure' than one which works using UDP, but there are a lot of other factors that go into security and doesn't quite fit here. Darren From Firewalls-Owner Mon Apr 19 15:24:14 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01443; Mon, 19 Apr 93 15:24:14 GMT Received: from norman.li.cubic.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01436; Mon, 19 Apr 93 08:23:48 PDT Received: by norman.li.cubic.com (5.67/1.34a) id AA06146; Mon, 19 Apr 93 11:23:43 -0400 Date: Mon, 19 Apr 93 11:23:43 -0400 From: mischler@Cubic.COM (Dave Mischler) Message-Id: <9304191523.AA06146@norman.li.cubic.com> To: avalon@coombs.anu.edu.au Subject: Re: DNS over TCP Cc: FireWalls@GreatCircle.COM Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Another point I haven't seen anybody bring up is that the way you run a nameserver so it will handle individual requests but not allow zone transfers is by filtering TCP packets to port 53 (only recognized secondaries should be allowed through). Note that CERT has come out in favor of disallowing unfiltered zone transfers. Dave Mischler mischler@cubic.com From Firewalls-Owner Mon Apr 19 17:09:42 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01836; Mon, 19 Apr 93 17:09:42 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA01826; Mon, 19 Apr 93 10:09:38 PDT Message-Id: <9304191709.AA01826@mycroft.GreatCircle.COM> To: firewalls@GreatCircle.COM (Firewall Mailing List) Subject: Re: DNS over TCP In-Reply-To: Your message of Sun, 18 Apr 1993 12:39:29 -0400 Date: Mon, 19 Apr 93 10:09:36 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk "Louis A. Mamakos" writes: # > People have said that they block all UDP packets bar those from and to # > port 53 (the port assigned to DNS and used by nameservers). # # What about other UDP based services, like NTP (Network Time Protocol)? # It seems that disabling a complete class of network transport is a bit # of overkill. Unfortunately, that's about the only option you have to keep folks from exploiting security holes in RPC-based services such as NFS and Yellow Pages (aka NIS). By the nature of RPC, you don't know for certain what UDP port an RPC-based server is going to end up using (though NFS usually uses 2049; NFS is a special case, though, that's more predictable than the others). You end up having to block almost all UDP in order to keep people from getting at your RPC-based services. Fortunately, most of the troublesome services aren't offered under TCP, or you'd have the same problem there. NTP may be able to take advantage of the same loophole as DNS, if the well-known NTP port number is used as both source and destination port on NTP server-to-server traffic. client-to-server UDP traffic (whether it's DNS or NTP or whatever) through the packet filter is still a problem, though. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Wed Apr 21 17:00:53 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02203; Wed, 21 Apr 93 17:00:53 GMT Received: from cs.columbia.edu by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02196; Wed, 21 Apr 93 10:00:40 PDT Received: from tiemann.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad+jtt) with SMTP id AA05372; Wed, 21 Apr 1993 13:01:21 -0400 Received: by tiemann.cs.columbia.edu id AA09431 (5.65c/IDA-1.4.4.5/jba/jtt/ad for firewalls@greatcircle.com); Wed, 21 Apr 1993 13:01:18 -0400 Date: Wed, 21 Apr 93 13:01:18 EDT From: Alexander Dupuy To: avalon@coombs.anu.edu.au Cc: firewalls@GreatCircle.COM (Firewall Mailing List) Reply-To: dupuy@hudson.cs.columbia.edu Subject: Re: DNS over TCP In-Reply-To: Your message of Tue, 20 Apr 93 7:52:15 EST Message-Id: Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk > If zone transfers are a problem, why not use the BIND 4.8.3 source and > just hack them out all together ? Actually, bind 4.9, which just went into beta, has support for screening zone transfers hacked in already. This allows the administrator to specify those networks or hosts from which zone transfers will be allowed. Note that the filtering is done at the DNS level, and does not arbitrarily block all DNS/TCP connections, but only XFR requests. This is especially helpful if you use the IBM AIX version of netstat, which uses a TCP connection to the DNS nameserver (apparently because it expects to make a lot of DNS queries). The current beta is available via anonymous ftp from gatekeeper.dec.com. Kudos to Paul Vixie at DECWRL for coordinating the bind 4.9 effort, and for hacking the zone-transfer restriction so that it doesn't just block TCP requests entirely. @alex From Firewalls-Owner Wed May 19 22:45:09 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02029; Wed, 19 May 93 22:45:09 GMT Received: from gatekeeper.es.dupont.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02020; Wed, 19 May 93 15:44:58 PDT Received: by gatekeeper.es.dupont.com (5.65/ULTRIX-mjr-062991); id AA10382; Wed, 19 May 93 18:46:13 -0400 Received: from fallst.es.dupont.com by eplrx7.es.duPont.com (4.1/kdm-082991-main) id AA21216; Wed, 19 May 93 18:44:02 EDT Received: by fallst.es.dupont.com (Smail3.1.28.1 #1) id m0nvwfM-000GMIC; Wed, 19 May 93 18:31 EDT Message-Id: From: tkevans@fallst.es.dupont.com (Tim Evans) Subject: SUMMARY: DNS in Firewalled Environment To: firewalls@GreatCircle.COM Date: Wed, 19 May 1993 18:31:15 -0400 (EDT) Phone: (410) 877-7890; (302) 695-9353 Reply-To: tkevans@eplrx7.es.duPont.com X-Mailer: ELM [version 2.4 PL22beta3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2189 Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Last week, I wrote: >I'd like to hear peoples' views on appropriate ways to set up >DNS in firewalled environments, particularly with respect to >preventing information about hosts inside the firewall from >being broadcast to the world at large via DNS, while at the >same time providing info about the world outside to all the >internal hosts. > Paul Sangster (sangster@reston.ans.ne) wrote me about a commercial hardware/software combination called The InterLock. He wrote: >The InterLock is a commercial security service (leasable includes hardware/ >software/7x24 support). It provides a security-enhanced AIX kernel and >versions of FTP, TELNET, SMTP, X, NNTP and other security tools. The >InterLock falls into the category of ipforwarding turned off (which is >being discussed on the list currently), although its not a screening >router firewall. Instead it provides real application layer security with >user authentication, user-level restrictions, user-level auditing and >other functions at a higher level (like control over get vs put in ftp). > >If you are interested in more information let me know we have a white >paper available. I received one other reply, which I could not figure out whether it was serious or smartass, so won't mention the sender's name. The suggestion was to "not register my domain". Perhaps I missed something, but I thought one had to register one's domain to be on the Internet and to use DNS. How I could do what I wanted with an unregistered domain is beyond me. If the sender wants to elaborate, I'd appreciate it, and I apologize in advance if I've offended him/her with my ignorance, if that's what turns out to be the case. Meanwhile, I've been studying the new O'Reilly book _DNS and Bind_ and believe the solution to what I'm after is to use "internal root DNS servers," which know only about the internals of my network and about a "normal" DNS server on the firewall machine, which knows only about itself and the outside world. This is discussed in Chapter 14 of the book. -- UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans INTERNET: tkevans@fallst.es.dupont.com Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047 From Firewalls-Owner Wed May 19 23:38:27 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02172; Wed, 19 May 93 23:38:27 GMT Received: from macsch.com (DRACO.MACSCH.COM) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA02165; Wed, 19 May 93 16:38:07 PDT Received: from [161.34.1.6] by macsch.com (5.61/SMI-4.1-07) id AA25192; Wed, 19 May 93 16:39:17 -0700 Received: from canismajor.is.macsch.com by convex.is.macsch.com (5.64/2.0) id AA02473; Wed, 19 May 93 16:37:08 -0700 Received: by canismajor.is.macsch.com (4.1/2.0) id AA05070; Wed, 19 May 93 16:39:00 PDT Date: Wed, 19 May 93 16:39:00 PDT From: todd@macsch.com (Todd Williams) Message-Id: <9305192339.AA05070@canismajor.is.macsch.com> To: firewalls@GreatCircle.COM Subject: Re: SUMMARY: DNS in Firewalled Environment Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk At 6:31pm on Wed May 19 1993, tkevans@fallst.es.dupont.com (Tim Evans) said: > Last week, I wrote: > > >I'd like to hear peoples' views on appropriate ways to set up > >DNS in firewalled environments, particularly with respect to > >preventing information about hosts inside the firewall from > >being broadcast to the world at large via DNS, while at the > >same time providing info about the world outside to all the > >internal hosts. > > I received one other reply, which I could not figure out whether it was > serious or smartass, so won't mention the sender's name. The suggestion > was to "not register my domain". Perhaps I missed something, but I thought > one had to register one's domain to be on the Internet and to use DNS. > How I could do what I wanted with an unregistered domain is beyond me. Right. If you're on the internet, your DNS must be using a registered name. > Meanwhile, I've been studying the new O'Reilly book _DNS and Bind_ > and believe the solution to what I'm after is to use "internal > root DNS servers," which know only about the internals of my network > and about a "normal" DNS server on the firewall machine, which knows > only about itself and the outside world. Well, I'm surprisingly disappointed that you didn't get an adequate response. Maybe nobody understood the question. I haven't tackled this problem at my site yet, so let me give you my blind-leading-the-blind reply: Smoot Carl-Mitchell of Texas Internet Consulting has developed something that will do exactly what you want, I think. I think they are hacks to DNS which allow you to run DNS out to the Internet from one side of your firewall, while running a slightly different DNS internal to your firewall. This is a common problem for people who want to hide internal host names, etc. His address is smoot@tic.com, or you can just get the package via FTP from tic.com, I think. Here's some of the previous discussion about this topic: At 11:56am on Tue Dec 22 1992, Donald R. Proctor (510/596-3828) said: > > Previously, avalon@coombs.anu.edu.au (Darren Reed) said: > > It has often been said that when setting up a firewall to allow DNS > > packets with both source and dest. of port 53 through. There seems > > to be an obvious flaw with this - what is to stop crackers using > > this 'hole' ? I don't recall if this was allowed just as far as the > > 'DMZ' or all the way through... > > The best approach is probably to set up an "internal" DNS domain and > an "external" DNS domain. The internal domain servers would talk to > internal root servers, and the external domain servers would talk to > the "real" root servers. > > That way you don't need to open up port 53 from the DMZ to the internal > network(s). > > Also, you may not have a need to advertise the name of every host on > your network to the outside world. In this case, the "external" DNS > server can operate with a very minimal DNS database configuration. Todd Williams UNIX Systems Supervisor todd@macsch.com (213) 259-4973 MacNeal-Schwendler Corp. ("MSC"), 815 Colorado Blvd., Los Angeles, CA 90041 "Solaris 2.0 -- It's enough to make you leave the company." -Rob Kolstad From Firewalls-Owner Thu May 20 15:18:12 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04895; Thu, 20 May 93 15:18:12 GMT Received: from lehman.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA04877; Thu, 20 May 93 08:17:46 PDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA02877; Thu, 20 May 93 11:18:34 EDT Received: from lehman.com by shearson.com (4.1/LB-0.6) id AA03209; Thu, 20 May 93 11:18:31 EDT Received: from shearson.com ([192.9.140.112]) by lehman.com (4.1/LB 0.1) id AA02874; Thu, 20 May 93 11:18:29 EDT Received: from snark.shearson.com by shearson.com (4.1/LB-0.6) id AA03206; Thu, 20 May 93 11:18:28 EDT Received: by snark.shearson.com (4.1/SMI-4.1) id AA11170; Thu, 20 May 93 11:18:27 EDT Message-Id: <9305201518.AA11170@snark.shearson.com> To: tkevans@eplrx7.es.dupont.com Cc: firewalls@GreatCircle.COM Subject: Re: SUMMARY: DNS in Firewalled Environment In-Reply-To: Your message of "Wed, 19 May 1993 18:31:15 EDT." Reply-To: pmetzger@lehman.com X-Reposting-Policy: redistribute only with permission Date: Thu, 20 May 1993 11:18:26 -0400 From: "Perry E. Metzger" Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Tim Evans says: > Last week, I wrote: > > >I'd like to hear peoples' views on appropriate ways to set up > >DNS in firewalled environments, particularly with respect to > >preventing information about hosts inside the firewall from > >being broadcast to the world at large via DNS, while at the > >same time providing info about the world outside to all the > >internal hosts. I'm sorry no one really answered you. I suspect everyone assumed someone else would. Here at Lehman, we have an internal and external DNS server. Externally, we just show a wildcard MX for our domain and the records for the firewall machine. Internally, we "do the right thing". Setting this up was quite trivial. > Paul Sangster (sangster@reston.ans.ne) wrote me about a commercial > hardware/software combination called The InterLock. He wrote: > > >The InterLock is a commercial security service (leasable includes hardware/ ANS basically leases you an RS/6000 with their firewall software. You can do everything they do for you for free with your own hardware using software available fro free from the net. Personally, I wouldn't touch their product with a long pole. They are very agressive about pushing the stuff to whomever sends out inquiries anywhere on the net, but I've never seen the utility of leasing an RS/6000 from them with their proprietary software other than the fact that being an IBM affiliate this helps them improve IBM's lackluster workstation sales. > Meanwhile, I've been studying the new O'Reilly book _DNS and Bind_ > and believe the solution to what I'm after is to use "internal > root DNS servers," which know only about the internals of my network > and about a "normal" DNS server on the firewall machine, which knows > only about itself and the outside world. This is discussed in > Chapter 14 of the book. A pretty good idea. Perry Metzger From Firewalls-Owner Thu May 20 17:17:20 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05602; Thu, 20 May 93 17:17:20 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05593; Thu, 20 May 93 10:17:14 PDT Message-Id: <9305201717.AA05593@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 10:17:13 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Just noticed that somewhere along the line during this debate, "Firewalls-Owner" got substituted for "Firewalls", and most of you haven't been seeing this exchange. I'll ferret out the other messages that got sent to the wrong address, and forward them. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 ------- Forwarded Message Return-Path: brent@GreatCircle.COM Return-Path: Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05506; Thu, 20 May 93 10:09:41 PDT Message-Id: <9305201709.AA05506@mycroft.GreatCircle.COM> To: rmdupont@irsc.gmeds.com (R. Michael Dupont) Cc: tkevans@eplrx7.es.duPont.com, Firewalls-Owner@GreatCircle.COM Subject: Re: DNS in Firewalled Environment In-Reply-To: Your message of Thu, 20 May 93 10:11:13 EST Date: Thu, 20 May 93 10:09:40 -0700 From: Brent Chapman Regarding the suggestion of using a bogus domain name as a way of ensuring that outsiders can't get at your DNS data... Don't. Everybody who does that (or similar things, like inventing IP addresses out of the blue, rather than registering them) because "WE'll never connect to the Internet" has come to regret it, and it's a major project to fix it a couple of years down the road. You might as well do things "right", right from the start. It will save you untold time and trouble later. There are other ways to hide your internal DNS data from prying eyes, one of which I've described before and will again shortly in a separate message. - -Brent - -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 ------- End of Forwarded Message From Firewalls-Owner Thu May 20 17:19:32 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05634; Thu, 20 May 93 17:19:32 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05624; Thu, 20 May 93 10:19:24 PDT Message-Id: <9305201719.AA05624@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 10:19:23 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Here's the only other misdirected message that I could find. -Brent ------- Forwarded Message Return-Path: rmdupont@irsc.gmeds.com Return-Path: Received: from irsc.gmeds.com ([192.57.20.10]) by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015)id AA04840; Thu, 20 May 93 08:10:06 PDT Received: by irsc.gmeds.com (4.1/EDS-1.0) id AA06861; Thu, 20 May 93 10:11:13 EST Date: Thu, 20 May 93 10:11:13 EST From: rmdupont@irsc.gmeds.com (R. Michael Dupont) Message-Id: <9305201511.AA06861@irsc.gmeds.com> To: tkevans@eplrx7.es.duPont.com, Firewalls-Owner@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Cc: rmdupont@irsc.gmeds.com >From the SERIOUS SMARTASS . . . > From tkevans@fallst.es.dupont.com Wed May 19 17:46:31 1993 > From: tkevans@fallst.es.dupont.com (Tim Evans) > Subject: Re: DNS in Firewalled Environment > To: rmdupont@irsc.gmeds.com (R. Michael Dupont) > Date: Wed, 19 May 1993 18:35:40 -0400 (EDT) > In-Reply-To: <9305142141.AA17179@irsc.gmeds.com> from "R. Michael Dupont" at May 14, 93 04:41:17 p> Phone: (410) 877-7890; (302) 695-9353 > Reply-To: tkevans@eplrx7.es.duPont.com > > Quoth R. Michael Dupont: > > > >> I'd like to hear peoples' views on appropriate ways to set up > >> DNS in firewalled environments, particularly with respect to > >> preventing information about hosts inside the firewall from > >> being broadcast to the world at large via DNS, while at the > >> same time providing info about the world outside to all the > >> internal hosts. > >> > >> Thanks. > >> > >How about not registering your domain? > > > I'm not sure I understand what you mean. If you're being sarcastic, > I guess I'm too dumb to appreciate the sarcasm. If you have a substantive > response, please send it. > > -- > UUCP: {rutgers|ames|uunet}!mimsy!wb3ffv!fallst!tkevans > INTERNET: tkevans@fallst.es.dupont.com > Tim Evans 2201 Brookhaven Ct, Fallston, MD 21047 > I am serious, but I guess my response needs a little more substance to it. By not registering a domain, the ROOT servers cannot resolve any unregistered HOST.DOMAIN.OF.MY.CHOICE because they do not know where the SOA resides. You (as the Source-Of-Authority) do, and can provide proper resolution for hosts within your domain. You can also resolve any registered domains because you are able to access the ROOT server, then the SOA servers containing the info desired. Yes, this could be creating conflicts if Ed's Drywall Supplies wanted to use an unregistered EDS.com domain. Mail from those users would (probably) never get to users at Electronic Data Systems, and vice-versa. If you were to use an unregistered domain, I would suggest not ending it with an acronym of less than three letters, so that there is no conflict with true registered domains (i.e. those in COM, EDU, GOV, MIL, ORG, NET, US, AZ, etc.) You might set up (using yourself as an example) a domain such as DUPONT, with a sub-domain of ES, and a host named FALLST, so that your internal email would be sent to tkevans@fallst.es.dupont. I might set up my own domain, and have my internal mail addressed to mike@smartass.dupont. Want to know about my host addresses? You have to find my SOA nameserver, and I'm not telling! You MUST apply for an address range that is registered prior to interconnecting to the Internet, so that there are no duplications. The address is not equal to a domain name, but is a separate issue for "NAME <--> ADDRESS" resolutions. No registered domain name ===> no address resolution for users in the Internet. Heresy!?! I am not suggesting this to create anarchy within the network, but as a "ONE-WAY MIRROR" method of Internet connectivity. The fact that there is no resolution could cause you problems with Anybody know of hitches to this type of a setup? Tim: No blood, no foul, no offense taken. - -- Mike +----------------------------------RMD19------------------------------------+ | R. Michael Dupont, Indiana Regional Support Cntr, Electronic Data Systems | | Data Networks Manager, Monday - Friday, 0800 - 1700 EST (1300 - 2200 GMT) | | Voice: (317)240-5823, GM: 8*360-5823, Pager: 928-1361, FAX: (317)240-5622 | | Paper: 2601 Fortune Circle East, Suite 100C, Indianapolis, IN 46241-5513 | | Internet: rmdupont@irsc.gmeds.com, DECUServe: dupont@Eisner.DECUS.Org | +---------------------------------------------------------------------------+ ------- End of Forwarded Message From Firewalls-Owner Thu May 20 17:36:52 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05718; Thu, 20 May 93 17:36:52 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05704; Thu, 20 May 93 10:36:45 PDT Message-Id: <9305201736.AA05704@mycroft.GreatCircle.COM> To: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 10:36:44 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk Here's a brief overview of how I set up DNS for my Internet-connected clients that don't want to advertise all their internal hosts. Basicly, the key realization is that the DNS clients on a machine don't have to talk to the DNS server on that same machine. In other words, just because there's a DNS server on a machine, there's nothing wrong with (and often advantages to) redirecting that machine's DNS client activity to a DNS server on another machine. Here's how I use that little factoid to my advantage... First, you set up a DNS server that the outside world can talk to. You set this server up so that it claims to be authoritative for your domains. In fact, all this server knows is what you want the outside world to know; the names and addresses of your gateways, your wildcard MX records, and so forth. This is the "public" server. Then, you set up a DNS server on an internal machine. This server also claims to be authoritiative for your domains; unlike the public server, this one is telling the truth. This is your "normal" nameserver, into which you put all your "normal" DNS stuff. You also set this server up to forward queries that it can't resolve to the public server (using a "forwarders" line in /etc/named.boot on a UNIX machine, for example). Finally, you set up all your DNS clients (the /etc/resolv.conf file on a UNIX box, for instance), including the ones on the machine with the public server, to use the INTERNAL server. This is the key. This is how it works... An internal client asking about an internal host asks the internal server, and gets an answer; an internal client asking about an external host asks the internal server, which asks the public server, which asks the Internet, and the answer is relayed back. A client on the public server works just the same way. An external client, however, asking about an internal host gets back the "restricted" answer from the public server. I'm assuming that there's a packet filtering firewall between these two servers that will allow them to talk DNS to each other, but that's it, but restricts DNS between other hosts. If you don't have a packet filtering firewall, then this whole scheme is kind of pointless; somebody can contact your internal name server (all they have to do is find it) and get all the "real" data. There's another trick that's useful in this scheme: wildcard PTR records (bet you didn't know you could do that! :-) in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for any of your non-public hosts to return something like "unknown.YOUR.DOMAIN" (i.e., "unknown.GreatCircle.COM") rather than an error. This satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu May 20 17:50:34 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05777; Thu, 20 May 93 17:50:34 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05766; Thu, 20 May 93 10:50:03 PDT Message-Id: <9305201750.AA05766@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu May 20 13:49:47 EDT 1993 To: Brent Chapman Cc: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 13:49:46 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk There's another trick that's useful in this scheme: wildcard PTR records (bet you didn't know you could do that! :-) in your IN-ADDR.ARPA domains. These cause an an address-to-name lookup for any of your non-public hosts to return something like "unknown.YOUR.DOMAIN" (i.e., "unknown.GreatCircle.COM") rather than an error. This satisfies anonymous FTP sites like ftp.uu.net that insist on having a name for the machines they talk to. No, it won't necessarily satisfy such sites. Many machines validate the results of gethostbyaddr() by doing a gethostbyname() call; if the latter doesn't return the actual IP address, the value returned by the gethostbyaddr() call isn't believed. For your idea to work, unknown.YOUR.DOMAIN would have to have an A record for every machine you own that could possibly talk to the outside world. Apart from the fact that you might not want to give out that information, you'll break lots of machines that can't handle that many A records coming back at them. From Firewalls-Owner Thu May 20 17:52:41 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05800; Thu, 20 May 93 17:52:41 GMT Received: from rara.ossi.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA05793; Thu, 20 May 93 10:52:13 PDT Received: from nym.ossi.com (nym.ossi.com [192.240.2.13]) by rara.ossi.com (ALPHA-6.54/6.27) id KAA154; Thu, 20 May 1993 10:53:16 -0700 Received: from localhost (aegl@localhost) by nym.ossi.com (ALPHA-6.54/6.27) id KAA23870; Thu, 20 May993 10:53:15 -0700 Date: Thu, 20 May 1993 10:53:15 -0700 From: Tony Luck Message-Id: <199305201753.KAA23870@nym.ossi.com> To: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk R. Michael Dupont writes: > By not registering a domain, the ROOT servers cannot resolve any unregistered > HOST.DOMAIN.OF.MY.CHOICE because they do not know where the SOA resides. You > (as the Source-Of-Authority) do, and can provide proper resolution for hosts > within your domain. ... > Anybody know of hitches to this type of a setup? At least one problem ... several of the anonymous ftp servers are already set up to reject connections if they can't do a reverse lookup on the address that your connection comes from (and some then convert the name back to an address again to make sure that they match). This kind of autentication of connections is becoming more common as the number of bad guys on the net goes up, resulting in a decrease in the overall level of trust. If you don't have a registered domain, then you can't access the services that do this kind of checking. -Tony Luck From Firewalls-Owner Thu May 20 18:41:31 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06062; Thu, 20 May 93 18:41:31 GMT Received: from localhost by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06053; Thu, 20 May 93 11:40:11 PDT Message-Id: <9305201840.AA06053@mycroft.GreatCircle.COM> To: smb@research.att.com Cc: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment In-Reply-To: Your message of Thu, 20 May 93 13:49:46 EDT Date: Thu, 20 May 93 11:40:09 -0700 From: Brent Chapman Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk # There's another trick that's useful in this scheme: wildcard # PTR records (bet you didn't know you could do that! :-) in # your IN-ADDR.ARPA domains. These cause an an address-to-name # lookup for any of your non-public hosts to return something # like "unknown.YOUR.DOMAIN" (i.e., "unknown.GreatCircle.COM") # rather than an error. This satisfies anonymous FTP sites like # ftp.uu.net that insist on having a name for the machines they # talk to. # # No, it won't necessarily satisfy such sites. Many machines validate # the results of gethostbyaddr() by doing a gethostbyname() call; if # the latter doesn't return the actual IP address, the value returned # by the gethostbyaddr() call isn't believed. For your idea to work, # unknown.YOUR.DOMAIN would have to have an A record for every machine # you own that could possibly talk to the outside world. Apart from # the fact that you might not want to give out that information, you'll # break lots of machines that can't handle that many A records coming # back at them. I have yet to encounter one of these sites. Every anonymous FTP site I've run into so far wanted (at most) a name; they didn't care if that name mapped back to the address you were coming from. So yes, in theory, this is a problem. In practice, it doesn't seem to be a problem. This is the "double reverse lookup" argument from early in the history of the Firewalls mailing list. I really didn't mean to start it up again; anybody who's interested should go back through the archives to find the old discussions on the subject. -Brent -- Brent Chapman Great Circle Associates Brent@GreatCircle.COM 1057 West Dana Street +1 415 962 0841 Mountain View, CA 94041 From Firewalls-Owner Thu May 20 21:05:21 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06910; Thu, 20 May 93 21:05:21 GMT Received: from research.att.com by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA06901; Thu, 20 May 93 14:05:06 PDT Message-Id: <9305202105.AA06901@mycroft.GreatCircle.COM> From: smb@research.att.com Received: by gryphon; Thu May 20 17:04:23 EDT 1993 To: Brent Chapman Cc: Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Date: Thu, 20 May 93 17:04:22 EDT Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk I have yet to encounter one of these sites. Every anonymous FTP site I've run into so far wanted (at most) a name; they didn't care if that name mapped back to the address you were coming from. So yes, in theory, this is a problem. In practice, it doesn't seem to be a problem. I confess that I'm surprised. SunOS's gethostbyaddr() call will return NULL if the cross-check fails. Perhaps folks sophisticated enough to have replaced their ftp daemons have also replaced their resolver libraries without being aware of the division of labor? From Firewalls-Owner Fri May 21 15:25:17 1993 Return-Path: Firewalls-Owner Return-Path: Received: by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09922; Fri, 21 May 93 15:25:17 GMT Received: from mercury.house.gov by mycroft.GreatCircle.COM (4.1/SMI-4.1/Brent-921015) id AA09913; Fri, 21 May 93 08:25:09 PDT Received: from cobalt.house.gov by mercury.house.gov with SMTP (1.37.109.4/16.2) id AA04952; Fri, 21 May 93 11:25:10 -0400 Received: by cobalt.house.gov (AA03617); Fri, 21 May 93 11:26:59 -0700 Date: Fri, 21 May 93 11:26:59 -0700 From: Dorian Deane Message-Id: <9305211826.AA03617@cobalt.house.gov> To: brent@GreatCircle.COM, Firewalls@GreatCircle.COM Subject: Re: DNS in Firewalled Environment Sender: Firewalls-Owner@GreatCircle.COM Precedence: bulk rmdupont@irsc.gmeds.com writes: > By not registering a domain, the ROOT servers cannot resolve any unregistered > HOST.DOMAIN.OF.MY.CHOICE because they do not know where the SOA resides. You > (as the Source-Of-Authority) do, and can provide proper resolution for hosts > within your domain. You can also resolve any registered domains because you > are able to access the ROOT server, then the SOA servers containing the info > desired. ... > You have to find my SOA nameserver, and I'm not telling! ... > Anybody know of hitches to this type of a setup? The minor hitches have already been addressed by others. I just want to point out that there is only minor value in security by obscurity. Just because there is no _name_ associated with your network doesn't mean you're not reachable. In fact, adding that kind of secrecy might make the "target" just that much more attractive. Dorian Deane House Information Systems ddeane@cobalt.house.gov