Answering my own question to help future googlers. I spent about 3 hours on the phone with TAC; we finally got to the root cause of the issue.
The solution is to add a special NAT entry, which matches the IP address in the DNS A-Record when it arrives on the INSIDE interface.
object network DNS_NAT_masd1
description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
host 1.195.18.182
nat (DMZ,INSIDE) static 10.195.18.182
When I asked for a pointer to documentation that describes why DNS translation works this way, the TAC lead said that he didn't know of any that described this behavior. The TAC lead also mentioned that with more code, the ASA would know to automatically translate the DNS A-Record without explicitly adding object network DNS_NAT_masd1; however, that is not how the dns keyword for ASA NAT works today. For reasons that still are not completely clear yet, the ASA requires the DNS A-Record IP to match the <proxy_addr> in the NAT statement, using syntax similar to this...
object network obj-EXAMPLE
description NAT object explicitly for translating DNS A-Records
host <proxy_addr>
nat (<REAL_INTF>,<PROXY_INTF>) static <real_addr> dns
The difficulty is that this configuration is exactly backwards for what you need to do if you're going to nat regular "data plane" IP traffic through the firewall.
This is the whole configuration that works...
object network DMZ_NAT_masd1
host 10.195.18.182
description xlate masd1 NAT DMZ src 10.195.18.182 to INSIDE src 192.168.11.101
object network INSIDE_NAT_masd1
host 10.195.18.182
description xlate masd1 NAT INSIDE src 10.195.18.182 to DMZ src 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
host 1.195.18.182
description xlate A-Record DMZ src 1.195.18.182 to INSIDE src 10.195.18.182
!
object network DMZ_NAT_masd1
nat (DMZ,INSIDE) static 192.168.11.101
object network INSIDE_NAT_masd1
nat (INSIDE,DMZ) static 1.195.18.182
!!! DNS_NAT_masd1 is new
object network DNS_NAT_masd1
nat (DMZ,INSIDE) static 10.195.18.182 dns
Because they're in the same zone -- and thus the same subnet, the source must be rewritten to get the replies to pass back through NAT instead of being a direct reply.
When a local lan client attempts to connect to the public server address, the traffic will flow to the firewall. The firewall will rewrite the destination and forward the traffic to the local lan server address. If the firewall doesn't change the source as well, the server will see the source as being on the local lan, and it's replies will be sent direct to the local lan client using the local lan server address. Without it passing back through the firewall, the traffic will not make sense to the client (wrong tcp sequence numbers, and wrong IP address.)
Best Answer
i think you have pool of real IP with GW and DNS so no you don't need any NAT on the PIX . you just need to confirm the next with ISP
i just wonder why you configure DHCP on the PIX , in such case PIX acting as next hub for your FW and may any L3 device even the FW acting as your DHCP server.
i such case my dear PIX act as a router , just route out subnets get from palo alto to outside and vice versa . in such senario NAT occured only on palo alto which already has real IP as i mentained before