Discussion:
NAT and Question Section Mismatch
(too old to reply)
John Wiles
2020-04-17 20:26:17 UTC
Permalink
Hello all,

I am running into a problem that I think is caused by either a misconfiguration in Bind9, our Cisco NAT, or perhaps both.

The scenario:

We host our own sites locally, including internal and external DNS. The external dns servers are delegated for reverse lookups. The NAT is a static one.

When I am on our internal network, I am able to query both servers and get the appropriate external ip address. However, when I try to do the same thing externally I get "Question section mismatch: got 6.1.1.10.in-addr.arpa/PTR/IN."

Some online tools will resolve the public ip to the appropriate hostname, but they will also show the ip as 10.1.1.6. Normally this wouldn't be an issue except that I think it is the reason for some emails not being delivered.

Any help or guidance is greatly appreciated.

John
Tony Finch
2020-04-17 21:10:54 UTC
Permalink
Post by John Wiles
I am running into a problem that I think is caused by either a
misconfiguration in Bind9, our Cisco NAT, or perhaps both.
When I am on our internal network, I am able to query both servers and
get the appropriate external ip address. However, when I try to do the
same thing externally I get "Question section mismatch: got
6.1.1.10.in-addr.arpa/PTR/IN."
I bet this is a PIX/ASA fixup fuxup.

Tony.
--
f.anthony.n.finch <***@dotat.at> http://dotat.at/
Humber, Thames: Northeast 4 or 5, occasionally 6 until later in Thames.
Moderate, becoming slight later in Thames. Showers, mainly in Thames. Good,
occasionally moderate.
John Wiles
2020-04-20 03:17:51 UTC
Permalink
Post by Tony Finch
Post by John Wiles
I am running into a problem that I think is caused by either a
misconfiguration in Bind9, our Cisco NAT, or perhaps both.
When I am on our internal network, I am able to query both servers and
get the appropriate external ip address. However, when I try to do the
same thing externally I get "Question section mismatch: got
6.1.1.10.in-addr.arpa/PTR/IN."
I bet this is a PIX/ASA fixup fuxup.
Tony.
Tony thanks for the response.

I'm assuming that applies to either DNS inspection and/or the fixup command. I'm asking the person that handles the cisco config to review.

I also just realized I forgot to mention that it is a 2911 ISR.

John
John Wiles
2020-04-21 18:08:24 UTC
Permalink
-----Original Message-----
From: John Wiles
Sent: Sunday, April 19, 2020 11:18 PM
Subject: RE: NAT and Question Section Mismatch
Post by Tony Finch
Post by John Wiles
I am running into a problem that I think is caused by either a
misconfiguration in Bind9, our Cisco NAT, or perhaps both.
When I am on our internal network, I am able to query both servers
and get the appropriate external ip address. However, when I try to
do the same thing externally I get "Question section mismatch: got
6.1.1.10.in-addr.arpa/PTR/IN."
I bet this is a PIX/ASA fixup fuxup.
Tony.
Tony thanks for the response.
I'm assuming that applies to either DNS inspection and/or the fixup
command. I'm asking the person that handles the cisco config to review.
I also just realized I forgot to mention that it is a 2911 ISR.
John
After going through the router config my cisco person is pretty sure that there is nothing in the configuration that is causing this.
server 72.162.32.4
Default server: 72.162.32.4
Address: 72.162.32.4#53
72.162.32.2
2.32.162.72.in-addr.arpa name = gw.iotis.org.
72.162.32.3
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN
;; connection timed out; no servers could be reached
72.162.32.4
;; ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN
;; ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN
;; ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN
;; connection timed out; no servers could be reached
72.162.32.19
19.32.162.72.in-addr.arpa name = badmx2.iotis.org.
72.162.32.18
18.32.162.72.in-addr.arpa name = badmx.iotis.org.
Matthew Richardson
2020-04-21 18:55:10 UTC
Permalink
Out of interest, what "ip inspect" settings exist in the Cisco 2911 config?

Do any of these reference "dns"? If so, this may be your problem...

Best wishes,
Matthew

------
Date: Tue, 21 Apr 2020 14:08:24 -0400
Subject: RE: NAT and Question Section Mismatch
-----Original Message-----
From: John Wiles
Sent: Sunday, April 19, 2020 11:18 PM
Subject: RE: NAT and Question Section Mismatch
Post by Tony Finch
Post by John Wiles
I am running into a problem that I think is caused by either a
misconfiguration in Bind9, our Cisco NAT, or perhaps both.
When I am on our internal network, I am able to query both servers
and get the appropriate external ip address. However, when I try to
do the same thing externally I get "Question section mismatch: got
6.1.1.10.in-addr.arpa/PTR/IN."
I bet this is a PIX/ASA fixup fuxup.
Tony.
Tony thanks for the response.
I'm assuming that applies to either DNS inspection and/or the fixup
command. I'm asking the person that handles the cisco config to review.
I also just realized I forgot to mention that it is a 2911 ISR.
John
After going through the router config my cisco person is pretty sure that there is nothing in the configuration that is causing this.
server 72.162.32.4
Default server: 72.162.32.4
Address: 72.162.32.4#53
72.162.32.2
2.32.162.72.in-addr.arpa name = gw.iotis.org.
72.162.32.3
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN
;; connection timed out; no servers could be reached
72.162.32.4
;; ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN
;; ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN
;; ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN
;; connection timed out; no servers could be reached
72.162.32.19
19.32.162.72.in-addr.arpa name = badmx2.iotis.org.
72.162.32.18
18.32.162.72.in-addr.arpa name = badmx.iotis.org.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
John Wiles
2020-04-21 19:14:57 UTC
Permalink
The only ip inspect lines that I could find in the current config are:

ip inspect dns-timeout 7200
ip inspect name CCP_HIGH dns

John
-----Original Message-----
Matthew Richardson
Sent: Tuesday, April 21, 2020 2:55 PM
Subject: Re: NAT and Question Section Mismatch
Out of interest, what "ip inspect" settings exist in the Cisco 2911 config?
Do any of these reference "dns"? If so, this may be your problem...
Best wishes,
Matthew
------
Date: Tue, 21 Apr 2020 14:08:24 -0400
Subject: RE: NAT and Question Section Mismatch
-----Original Message-----
From: John Wiles
Sent: Sunday, April 19, 2020 11:18 PM
Subject: RE: NAT and Question Section Mismatch
Post by Tony Finch
Post by John Wiles
I am running into a problem that I think is caused by either a
misconfiguration in Bind9, our Cisco NAT, or perhaps both.
When I am on our internal network, I am able to query both
servers and get the appropriate external ip address. However,
when I try to do the same thing externally I get "Question
section mismatch: got 6.1.1.10.in-addr.arpa/PTR/IN."
I bet this is a PIX/ASA fixup fuxup.
Tony.
Tony thanks for the response.
I'm assuming that applies to either DNS inspection and/or the fixup
command. I'm asking the person that handles the cisco config to review.
I also just realized I forgot to mention that it is a 2911 ISR.
John
After going through the router config my cisco person is pretty sure that
there is nothing in the configuration that is causing this.
But I'm not so certain since it appears to only affect the hosts that are in the
server 72.162.32.4
Default server: 72.162.32.4
Address: 72.162.32.4#53
72.162.32.2
2.32.162.72.in-addr.arpa name = gw.iotis.org.
72.162.32.3
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN ;;
;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN ;; ;;
Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN ;;
connection timed out; no servers could be reached
72.162.32.4
;; ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN ;;
;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN ;; ;;
Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN ;;
connection timed out; no servers could be reached
72.162.32.19
19.32.162.72.in-addr.arpa name = badmx2.iotis.org.
72.162.32.18
18.32.162.72.in-addr.arpa name = badmx.iotis.org.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Ondřej Surý
2020-04-21 19:30:29 UTC
Permalink
There was a setting in Cisco which would handle the host behind
the NAT differently when the DNS traffic passed the matching NAT.

I found a bug in the Cisco devices more than 10+ years ago when
it would mangle the TTL to `0`. I don’t really remember the details
though, but it’s not only the `ip inspect` that might be at fault.

Ondrej
--
Ondřej SurÃœ
Post by John Wiles
ip inspect dns-timeout 7200
ip inspect name CCP_HIGH dns
John
-----Original Message-----
Matthew Richardson
Sent: Tuesday, April 21, 2020 2:55 PM
Subject: Re: NAT and Question Section Mismatch
Out of interest, what "ip inspect" settings exist in the Cisco 2911 config?
Do any of these reference "dns"? If so, this may be your problem...
Best wishes,
Matthew
------
Date: Tue, 21 Apr 2020 14:08:24 -0400
Subject: RE: NAT and Question Section Mismatch
-----Original Message-----
From: John Wiles
Sent: Sunday, April 19, 2020 11:18 PM
Subject: RE: NAT and Question Section Mismatch
Post by Tony Finch
Post by John Wiles
I am running into a problem that I think is caused by either a
misconfiguration in Bind9, our Cisco NAT, or perhaps both.
When I am on our internal network, I am able to query both
servers and get the appropriate external ip address. However,
when I try to do the same thing externally I get "Question
section mismatch: got 6.1.1.10.in-addr.arpa/PTR/IN."
I bet this is a PIX/ASA fixup fuxup.
Tony.
Tony thanks for the response.
I'm assuming that applies to either DNS inspection and/or the fixup
command. I'm asking the person that handles the cisco config to review.
I also just realized I forgot to mention that it is a 2911 ISR.
John
After going through the router config my cisco person is pretty sure that
there is nothing in the configuration that is causing this.
But I'm not so certain since it appears to only affect the hosts that are in the
server 72.162.32.4
Default server: 72.162.32.4
Address: 72.162.32.4#53
72.162.32.2
2.32.162.72.in-addr.arpa name = gw.iotis.org.
72.162.32.3
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN ;;
;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN ;; ;;
Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN ;;
connection timed out; no servers could be reached
72.162.32.4
;; ;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN ;;
;; Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN ;; ;;
Question section mismatch: got 25.1.1.10.in-addr.arpa/PTR/IN ;;
connection timed out; no servers could be reached
72.162.32.19
19.32.162.72.in-addr.arpa name = badmx2.iotis.org.
72.162.32.18
18.32.162.72.in-addr.arpa name = badmx.iotis.org.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
Carl Byington
2020-04-21 22:16:45 UTC
Permalink
On Tue, 2020-04-21 at 14:08 -0400, John Wiles wrote:
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN

tcpdump is your friend.

Dump the outgoing packets from your home connection to see exactly what
you are sending for:

dig 3.32.162.72.in-addr.arpa ptr @72.162.32.4 +nodnssec +norecur

Dump the incoming packets at your dns server to see what it is receiving
for that command. Any differences are probably generated by the cisco.
Dump the outgoing packets from your dns server, and the incoming packets
at your home connection also.
Mark Andrews
2020-04-21 23:03:35 UTC
Permalink
https://www.networkstraining.com/dns-doctoring-cisco-asa/
Post by John Wiles
Hello all,
I am running into a problem that I think is caused by either a misconfiguration in Bind9, our Cisco NAT, or perhaps both.
We host our own sites locally, including internal and external DNS. The external dns servers are delegated for reverse lookups. The NAT is a static one.
When I am on our internal network, I am able to query both servers and get the appropriate external ip address. However, when I try to do the same thing externally I get “Question section mismatch: got 6.1.1.10.in-addr.arpa/PTR/IN.”
Some online tools will resolve the public ip to the appropriate hostname, but they will also show the ip as 10.1.1.6. Normally this wouldn’t be an issue except that I think it is the reason for some emails not being delivered.
Any help or guidance is greatly appreciated.
John
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
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: ***@isc.org
Mark Andrews
2020-04-21 23:10:41 UTC
Permalink
The ultimate fix for this is to move to IPv6 so every device is universally addressable. NAT is a stop gap measure that is well past its use by date.
Post by Mark Andrews
https://www.networkstraining.com/dns-doctoring-cisco-asa/
Post by John Wiles
Hello all,
I am running into a problem that I think is caused by either a misconfiguration in Bind9, our Cisco NAT, or perhaps both.
We host our own sites locally, including internal and external DNS. The external dns servers are delegated for reverse lookups. The NAT is a static one.
When I am on our internal network, I am able to query both servers and get the appropriate external ip address. However, when I try to do the same thing externally I get “Question section mismatch: got 6.1.1.10.in-addr.arpa/PTR/IN.”
Some online tools will resolve the public ip to the appropriate hostname, but they will also show the ip as 10.1.1.6. Normally this wouldn’t be an issue except that I think it is the reason for some emails not being delivered.
Any help or guidance is greatly appreciated.
John
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
bind-users mailing list
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: ***@isc.org
Reindl Harald
2020-04-21 23:37:10 UTC
Permalink
Post by Ondřej Surý
There was a setting in Cisco which would handle the host behind
the NAT differently when the DNS traffic passed the matching NAT.
I found a bug in the Cisco devices more than 10+ years ago when
it would mangle the TTL to `0`. I don’t really remember the details
though, but it’s not only the `ip inspect` that might be at fault.
cisco dns ALG even mangles the TTL of CNAMES within a zone-transfer
which was the reason to set up a vpn peer to avoid zero TTLs on public
slaves

no ip nat service alg tcp dns
no ip nat service alg udp dns
John Wiles
2020-04-22 11:27:50 UTC
Permalink
Carl,

The output from the tcpdumps on both machines.

From my local:

226 13.386290 172.16.1.103 72.162.32.4 DNS 107 Standard query 0x8148 PTR 3.32.162.72.in-addr.arpa OPT
227 13.405397 72.162.32.4 172.16.1.103 DNS 93 Standard query response 0x8148 Refused PTR 17.1.1.10.in-addr.arpa OPT
307 18.385705 172.16.1.103 72.162.32.4 DNS 107 Standard query 0x8148 PTR 3.32.162.72.in-addr.arpa OPT
308 18.402629 72.162.32.4 172.16.1.103 DNS 93 Standard query response 0x8148 Refused PTR 17.1.1.10.in-addr.arpa OPT
357 23.386698 172.16.1.103 72.162.32.4 DNS 107 Standard query 0x8148 PTR 3.32.162.72.in-addr.arpa OPT
358 23.404178 72.162.32.4 172.16.1.103 DNS 93 Standard query response 0x8148 Refused PTR 17.1.1.10.in-addr.arpa OPT
492 35.373711 172.16.1.103 72.162.32.4 DNS 107 Standard query 0xa388 PTR 5.32.162.72.in-addr.arpa OPT
493 35.391667 72.162.32.4 172.16.1.103 DNS 149 Standard query response 0xa388 No such name PTR 5.32.162.72.in-addr.arpa SOA ns.iotis.org OPT
541 44.408527 172.16.1.103 72.162.32.4 DNS 107 Standard query 0x2e67 PTR 6.32.162.72.in-addr.arpa OPT
542 44.426670 72.162.32.4 172.16.1.103 DNS 92 Standard query response 0x2e67 Refused PTR 6.1.1.10.in-addr.arpa OPT
634 49.408293 172.16.1.103 72.162.32.4 DNS 107 Standard query 0x2e67 PTR 6.32.162.72.in-addr.arpa OPT
635 49.427719 72.162.32.4 172.16.1.103 DNS 92 Standard query response 0x2e67 Refused PTR 6.1.1.10.in-addr.arpa OPT
689 54.408297 172.16.1.103 72.162.32.4 DNS 107 Standard query 0x2e67 PTR 6.32.162.72.in-addr.arpa OPT
690 54.425286 72.162.32.4 172.16.1.103 DNS 92 Standard query response 0x2e67 Refused PTR 6.1.1.10.in-addr.arpa OPT
755 62.891404 172.16.1.103 72.162.32.4 DNS 108 Standard query 0xd77a PTR 18.32.162.72.in-addr.arpa OPT
756 62.908737 72.162.32.4 172.16.1.103 DNS 192 Standard query response 0xd77a PTR 18.32.162.72.in-addr.arpa PTR badmx.iotis.org NS ns2.iotis.org NS ns.iotis.org A 72.162.32.3 A 72.162.32.4 OPT

From the dns server:

07:15:07.565369 IP 24.181.4.204.22196 > 10.1.1.25.53: 33096 [1au] PTR? 17.1.1.10.in-addr.arpa. (63)
07:15:07.565984 IP 10.1.1.25.53 > 24.181.4.204.22196: 33096 Refused- 0/0/1 (51)
07:15:12.562543 IP 24.181.4.204.22196 > 10.1.1.25.53: 33096 [1au] PTR? 17.1.1.10.in-addr.arpa. (63)
07:15:12.563134 IP 10.1.1.25.53 > 24.181.4.204.22196: 33096 Refused- 0/0/1 (51)
07:15:17.563820 IP 24.181.4.204.22196 > 10.1.1.25.53: 33096 [1au] PTR? 17.1.1.10.in-addr.arpa. (63)
07:15:17.564464 IP 10.1.1.25.53 > 24.181.4.204.22196: 33096 Refused- 0/0/1 (51)
07:15:29.551545 IP 24.181.4.204.10307 > 10.1.1.25.53: 41864 [1au] PTR? 5.32.162.72.in-addr.arpa. (65)
07:15:29.552158 IP 10.1.1.25.53 > 24.181.4.204.10307: 41864 NXDomain*- 0/1/1 (107)
07:15:38.586430 IP 24.181.4.204.44420 > 10.1.1.25.53: 11879 [1au] PTR? 6.1.1.10.in-addr.arpa. (62)
07:15:38.586935 IP 10.1.1.25.53 > 24.181.4.204.44420: 11879 Refused- 0/0/1 (50)
07:15:43.587602 IP 24.181.4.204.44420 > 10.1.1.25.53: 11879 [1au] PTR? 6.1.1.10.in-addr.arpa. (62)
07:15:43.588026 IP 10.1.1.25.53 > 24.181.4.204.44420: 11879 Refused- 0/0/1 (50)
07:15:48.584994 IP 24.181.4.204.44420 > 10.1.1.25.53: 11879 [1au] PTR? 6.1.1.10.in-addr.arpa. (62)
07:15:48.585537 IP 10.1.1.25.53 > 24.181.4.204.44420: 11879 Refused- 0/0/1 (50)
07:15:57.068551 IP 24.181.4.204.44089 > 10.1.1.25.53: 55162 [1au] PTR? 18.32.162.72.in-addr.arpa. (66)
07:15:57.069188 IP 10.1.1.25.53 > 24.181.4.204.44089: 55162*- 1/2/3 PTR badmx.iotis.org. (150)

I'm sending the above to our cisco guy, I had already assumed it is the nat as I had noticed yesterday that it was only affecting actual nated hosts.

John
-----Original Message-----
Byington via bind-users
Sent: Tuesday, April 21, 2020 6:17 PM
Subject: RE: NAT and Question Section Mismatch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
;; ;; Question section mismatch: got 17.1.1.10.in-addr.arpa/PTR/IN
tcpdump is your friend.
Dump the outgoing packets from your home connection to see exactly what
Dump the incoming packets at your dns server to see what it is receiving for
that command. Any differences are probably generated by the cisco.
Dump the outgoing packets from your dns server, and the incoming packets
at your home connection also.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEAREKAAYFAl6fcKwACgkQL6j7milTFsHWLACffvw6WJlQecTYmUWQ0al6szX
u
GncAn05uTakguddRQfrb3QlhMdhVl2gB
=hUGI
-----END PGP SIGNATURE-----
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
https://lists.isc.org/mailman/listinfo/bind-users
John Wiles
2020-04-22 13:42:16 UTC
Permalink
Thank you to everyone taking the time to reply and provide guidance with this problem.

Our cisco guy turned off alg on the nat for dns and our reverse dns lookups are now working properly.

Just to follow up, found this after searching using Ondřej Surý's description and Reindl Harald's replies. Amazing that cisco actually mentioned it in a document:

NAT DNS ALG Support
NAT application awareness includes support for the Domain Name System (DNS). An application-level gateway (ALG) translates IP addresses and port numbers embedded in the DNS payload when a NAT mapping is processed.

With CSCuc05660, for DNS payloads that are address-translated, the DNS time to live (TTL) value in CNAME entries is passed through. Before CSCuc05660 and before support for the ip nat service dns-reset-ttl command was added, the TTL value in the CNAME entries was reset by default.
-----Original Message-----
Reindl Harald
Sent: Tuesday, April 21, 2020 7:37 PM
Subject: Re: NAT and Question Section Mismatch
There was a setting in Cisco which would handle the host behind the
NAT differently when the DNS traffic passed the matching NAT.
I found a bug in the Cisco devices more than 10+ years ago when it
would mangle the TTL to `0`. I don’t really remember the details
though, but it’s not only the `ip inspect` that might be at fault.
cisco dns ALG even mangles the TTL of CNAMES within a zone-transfer which
was the reason to set up a vpn peer to avoid zero TTLs on public slaves
no ip nat service alg tcp dns
no ip nat service alg udp dns
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
https://lists.isc.org/mailman/li
Loading...