Odd PTR through cisco NAT behaviour.

[Mark Andrews]

In message <4bde94f10907131945n2f22dfe6j502111e545d2ad64 at mail.gmail.com>, Hokum
ae writes:
> I host a portable class C subnet (A portable /24): 192.75.X.X
> I run an instance of BIND 9.4.3_p2 on a NAT'd machine
> (2.6.29-gentoo-r5): 10.10.10.10
> The NAT is handled by a Cisco 1760
> 
> BIND is configured in a "Split View" INTERNAL/EXTERNAL configuration.

> The problem --
> PTR requests for the 2 MX servers: 192.75.x.50 and 192.75.x.51 are not
> being answered properly.
> Requests for the PTR records for mail.example101.com and
> mail2.example101.com respectively return status: SERVFAIL by dig.
> The log entry for those PTR requests are as follows (live example from
> intoDNS.com):
> 
> 
> 
> 11-Jul-2009 13:46:32.302 client 89.36.21.42#39533: view external:
> query: 10.10.10.10.in-addr.arpa IN PTR -E
> 11-Jul-2009 13:46:32.503 client 89.36.21.42#50709: view external:
> query: 10.10.10.10.in-addr.arpa IN PTR -E
> 11-Jul-2009 13:46:32.741 client 89.36.21.42#53332: view external:
> query: 10.10.10.10.in-addr.arpa IN PTR -E
> 11-Jul-2009 13:46:32.939 client 89.36.21.42#38387: view external:
> query: 10.10.10.10.in-addr.arpa IN PTR -E
> 11-Jul-2009 13:46:33.139 client 89.36.21.42#56996: view external:
> query: 10.10.10.10.in-addr.arpa IN PTR -E
> 11-Jul-2009 13:46:33.338 client 89.36.21.42#18754: view external:
> query: 10.10.10.10.in-addr.arpa IN PTR -E
> 11-Jul-2009 13:46:33.537 client 89.36.21.42#35442: view external:
> query: 10.10.10.10.in-addr.arpa IN PTR -E
> 11-Jul-2009 13:46:33.772 client 89.36.21.42#47101: view external:
> query: 10.10.10.10.in-addr.arpa IN PTR -E
> 
> 
> So it looks like "external" view requests are being NAT'd in, and then
> BIND is looking to the local 10.10.10.10.in-addr.arpa file for PTR
> info. This is wrong for several reasons, but I can't quite figure out
> why this behavior exists. Cisco understands A and PTR DNS requests and
> can NAT them in and out usually without any problem. So, I'm stumped.
> Any ideas what's going on here and what's needed to fix it are
> appreciated. I am hoping to avoid having to use IPTABLES to mark and
> rewrite all MX PTR queries to the correct reverse-zone, that shouldn't
> be necessary.

	Tell the cisco to stop translating or add the/a 10.IN-ADDR.ARPA
	zone to the external zone.
 
> Quote:
> Q. Does Cisco IOS NAT support Domain Name System (DNS) queries?
> 
> A. Yes. Cisco IOS NAT will translate the addresses that appear in DNS
> responses to name lookups (A queries) and inverse lookups (PTR
> queries). Therefore, if an outside host sends a name lookup to a DNS
> server on the inside, and that server responds with a local address,
> the NAT code will translate that local address to a global address.
> The opposite is also true. This is how Cisco supports IP addresses
> overlapping: an inside host queries an outside DNS server and the
> response contains an address that matches the access list specified on
> the outside source command, so the code translates the outside global
> address to an outside local address.
> 
> Time-to-live (TTL) values on all DNS resource records, which receive
> address translations in resource records payloads, are automatically
> set to zero.
> 
> Some relevant config data:
> 
> acl friendlies {
>   10.10.10.0/24;
>   localhost;
>   localnets;
> };
> 
> 
> 
> 
> options { directory "/var/bind";
>        allow-transfer { 192.75.X.X; 10.10.10.0/24; };
>        allow-query { any; };
>        allow-recursion { friendlies; };
       allow-query-cache { friendlies; };
>        dump-file "/var/bind/named.dump";
>        zone-statistics yes;
>        statistics-file "/var/bind/named.stats";
>        pid-file "/var/run/named/named.pid";
>        version "Go away!";
>        dnssec-enable yes;
>        dnssec-validation yes;
>        dnssec-lookaside . trust-anchor dlv.isc.org.;
> 
> 
> 
> 
> view "internal" {
>        match-clients { friendlies; };
> 
> zone "." IN {
>        type hint;
>        file "named.ca";
> };
> 
> zone "localhost" IN {
>        type master;
>        file "pri/localhost.zone";
>        allow-update { none; };
>        notify no;
> };
> 
> zone "127.in-addr.arpa" IN {
>        type master;
>        file "pri/127.zone";
>        allow-update { none; };
>        notify no;
> };
> 
> zone "10.in-addr.arpa" IN {
>      type master;
>      file "pri/10.zone";
>      allow-query { any; };
>      allow-update {none; };
>      notify no;
> 
>        };
> 
> };
> 
> 
> --SNIP--
> 
> 
> 
> view "external" {
> 
>        match-clients { any; };
>        recursion no;
> 
> zone "example101.com" IN {
>      type master;
>      file "example101.com.zone";
>      allow-query { any; };
>      allow-update { none; };
> };
> 
> zone "X.75.192.in-addr.arpa" IN {
>      type master;
>      file "pri/X.75.192.zone";
>      allow-query { any; };
>      allow-update {none; };
>      notify no;
>        };
> 
> };
> 
> 
> Any help is appreciated.
> _______________________________________________
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org