IXFR, NOTIFY, and NAT

[Eric S. Johansson]

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 of
>>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.

(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.

>>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.

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.

> 	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.

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.

---eric


---eric