This is a discussion on Re: Risks of patched servers behind de-randomizing NAT - DNS ; OT, I agree, but certainly relevant to the issue at hand. I noticed the same thing a couple of weeks ago after I upgraded to 9.4.2-P1. It is absolutely the PIX and will happen with 6.x through 8.x code. However, ...
OT, I agree, but certainly relevant to the issue at hand.
I noticed the same thing a couple of weeks ago after I upgraded to
9.4.2-P1. It is absolutely the PIX and will happen with 6.x through 8.x
However, this issue is related to how the code PATs outbound traffic and
can be resolved by setting up a static NAT for the nameserver.
You can do this on the fly by adding (adjusting for actual interface
static (inside,outside) ...
clear xlate local
clear xlate global
At that point the various DNS tests mentioned on the list should report
Of course, all this assumes you are being routed enough public IP
address space and have a free address to use...
On Fri, 2008-08-01 at 06:43 -0500, Kirk wrote:
> Mark Andrews wrote:
> >> David Carmean pisze:
> >>> I seem to have lost a message where somebody from ISC (Paul?) was going to
> >>> release an updated/new advisory regarding the source-port de-randomizing
> >>> effects of many NAT implementations will have upon patched servers.
> >> But why someone puts a DNS server behind a NAT? It's a bit nonsensical...
> > There are lots of reasons to put a recursive server behind
> > a NAT. It's something that just "should work" and does if
> > you arn't trying to introduce entroy by randomising ports.
> > Note. Not all NATs have bad behaviours in this respect. Some try
> > to preserve the internal port.
> > MArk
> This is slightly off topic. However, I thought it appropriate to share.
> At home I have two recursive servers sitting on a private lan behind a
> Cisco PIX 501. These servers are mostly to play with, but also provides
> recursion to all the nodes in my house.
> After upgrading these servers to the latest patched version of BIND, I
> tried the porttest query to test randomization. Well, both got POOR
> ratings. This led me to believe that my PIX was the culprit.
> Last night, I spent close to 30 with the Cisco help desk trying to get
> assistance, only to find that because my unit was out of warranty and I
> had no contract, they could be of no help. They suggested I open a
> "web-help" ticket with Cisco. This also returned no help for the same
> reason. Also, my appliance is already at the highest code OS leve.
> I guess those of us who purchased Cisco products that are out of
> warranty and under no contract are at risk until we purchase some new
> Sorry for the rant, but it "seemed" sort of appropriate here in this thread.
> - Kirk