Cisco – Is it possible to do DNS-based ACLs on a Cisco ASA

I don't see a way to get this working with 2 IPs on the same network with an ASA :/
The best solution I see is to put a router behind the ASA to do the NAT or reduce a lot TTL of ssl.customer.ch (to reduce downtime) then change its IP

There are reasons to go in either direction that you and others have mentioned.

Having a layer (kind of a pun) of abstraction in the form of static 1:1 NAT is kind of nice as you likely will not have to renumber internal hosts if your WAN IP block changes. However, the complexities and nuances that NAT introduces to packet flow through an ASA can be problematic when compared to simple routing and ACL checks.

My personal point of view is that NAT is here to stay with IPv4. For IPv4 stacks on hosts, I have no qualms with static NATing on the upstream firewall. For IPv6 stacks on hosts however, no NAT. On the ASA both IPv4 and IPv6 can be run side by side, with NAT for IPv4 and traditional routing for IPv6.

There is one other reason why you may want to go with static NAT and it deals with growth. The ASA does not support secondary IP addresses on interfaces. Say your upstream allocates you a /26 routed directly to your ASA's outside interface. You configure your ASA's dmz interface with the first host IP in the IP subnet leaving you 64 - 2 - 1 = 61 valid host IP's in the subnet to be used by your servers.

If you use all 61 remaining host IP's and need more you go to upstream and say hey I need another /26. They give it to you and route it again, directly to the outside IP of your ASA. You cannot assign the first host IP in the second block to your ASA's dmz interface as a secondary IP address like you can with IOS. This leaves you with a few options --

• Create another interface dmz2 on the ASA (not desirable)
• Give back the /26, ask for a /25, and renumber internally (not desirable)
• Perform static NAT (what we are arguing against doing in this example)

Next take the same paradigm -- this time with 1:1 static NAT outside <-> dmz from the beginning. We use all of the available IP's in our first /26 in 1:1 static NATs. We request a second /26 --

• You can request that the upstream route directly to your ASA outside interface IP directly -- saving you a few addresses as the upstream will not have to assign an address in the block as a secondary IP address on their equipment to be used as a gateway even though you won't need it. Note that most providers take the first 3 host IP addresses as part of VRRP/HSRP reducing your usables.
• If you don't request be directly routed the block the upstream will usually perform the latter half of the previous option. The ASA then proxy ARP's (as it likely does with your first block depending on how it is setup) for local-delivered traffic for those IP's on the broadcast domain to which the outside interface is a member.

Lesson: If you already have a public IP block on your outside interface, always request that subsequent blocks be directly routed to your outside interface IP. This will give you additional usable IP's and you can still static NAT just fine.

No matter direct routed or ASA proxy arp -- with 1:1 static NAT you can start using the second /26 without having to muck around with the dmz subnet. Once you outgrow your dmz subnet you will have to make some accommodations -- but again there is a layer of abstraction and you don't have to muck around on the WAN side.

Final Answer: It depends, but with IPv4 I lean toward NAT in your case.