IXFR, NOTIFY, and NAT

Mark_Andrews at isc.org Mark_Andrews at isc.org
Mon Sep 30 23:43:20 UTC 2002


> Mark_Andrews at isc.org wrote:
> >>"Jim Reid" <jim at rfc1035.com> wrote in message
> >>news:an1ouo$fuko$1 at isrv4.isc.org...
> >>Which is why you need static NAT, not dynamic NAT.  With a 1 to 1 mapping o
> f
> >>external address to internal address you can guarantee which host you hit
> >>and have appropriate reverse records.
> > 
> > 
> > 	getpeername() returns the NAT'd address not the real address.
> > 	A socks based appliction gets the real address.
> > 
> > 	["real" is the address the client wanted you to see.]
> 
> we could argue in circles on this point.  From my perspective, getting 
> the NAT public address is exactly the right thing for it to do because 
> it's a publicly routable address.  And on many application servers that 
> I have created, the address the client wanted you to see was the NAT 
> gateway public address because that's how you find your way back to the 
> service.
> 
> Broken protocols such as FTP or H.323 embed the IP address of the client 
> machine in the packet requiring diddling of said packet to make it look 
> right on the other side.  I contend that the fault of the protocol, not 
> address translation.

	FTP isn't broken.  It was designed for a peer-to-peer network
	with no NAT's in the middle because they didn't exist when it
	was designed.
 
> (bringing it back on topic) if there are problems with zone transfers or 
> dynamic DNS updates across address translation boundaries, and the 
> protocol is broken and should be fixed.

	As long as the NAT doesn't munge the DNS data it will transit a
	NAT fine.
 
> >>For host going out, yes I want them to all map to the same address because 
> I
> >>don't *want* external devices to originate packets to the internal
> >>workstations on my network.  In addition to the firewall rules blocking
> >>this, I find it usefull for there *not* to be a path at all.
> > 
> > 
> > 	This is just security by obscurity.  A plain firewall is just as
> > 	good at protecting your interal machines as a NAT'd firewall.
> 
> unfortunately, this old canard doesn't apply in this case.  Security 
> through obscurity applies to hiding information in in plain sight with 
> only minimal, easily discovered barriers to entry.  Using address 
> translation as a security feature is a valid technique because it 
> provides active information hiding and impedes an attacker from 
> discovering your internal network configuration (hosts, services etc.)
> 
> address translation is an important addition to a firewall or security 
> perimeter but it is not sufficient by itself to secure a network connection.
> 
> there are two very good reasons I can give you for using address 
> translation not pertaining to security:
> 
> 1) you get as many addresses as you need for your internal network
> 
> Nowadays, you're lucky to get a /28 address allocation for your network 
> and are more likely to get a /30 if you "aren't running any services". 
> This really sucks if you need a /23 internally.

	Well go to a ISP that can supply the number of addresses you need.
	There is no IP address shortage.  ISP's can get as many addresses
	as they need.
 
> 2) you are protected when your external IP address range changes
> 
> you're lucky to keep a bandwidth provider for a year nowadays if you are 
> a small shop and can't afford a Tier 1 service offering.  If you're even 
> more blessed you'll get notice that your service provider is changing 
> and you're getting a new IP address allocation in 30 days.  With address 
> translation you only have one point in the network to change as well as 
> your DNS records.  If your internal machines have publicly routable 
> addresses, you are in for a much bigger headache.

	Address changes can be completely automated.  It really isn't hard
	especially if you can route the new address before the old one
	disappears.  Yes I've had to renumber networks several times.

	DHCP and IP aliases have made the job so much easier than it was
	when I first had to do it.
 
> > 	NAT's don't work if they don't contain application proxies.
> 
> sorry.  This just isn't true.  I do dns queries across nat everyday 
> without any application proxies.  The basic port 53 query (TCP/UDP) work 
> just fine.  The only applications that need application proxies are ones 
> that have broken protocols.

	FTP isn't broken.  It needs a application proxy to transit a NAT.
 
> There is no excuse for writing broken protocols today.  Address 
> translation has been around long enough for people to know that it 
> exists and that it is in common use.  It'll probably be with us for at 
> least another 7 years because there is no evidence that IPv6 or 
> equivalent is coming any sooner.

	You can buy IPv6 tansport today.  All/most the OS vendors have
	IPv6 support.
 
	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews at isc.org


More information about the bind-users mailing list