Slave zero-TTL on CNAMES -> no ip nat service alg udp dns
Reindl Harald
h.reindl at thelounge.net
Thu Jun 5 18:18:00 UTC 2014
Am 05.06.2014 18:48, schrieb Ben Croswell:
> Cisco routers do have the ability to "doctor" DNS packets when doing NAT
argh - and it is on by default
"no ip nat service alg udp dns"
"no ip nat service alg tcp dns"
> When it doctors it sets the TTL to 0 but
> I dont know why it would only do it on CNAME records.
because that crap is broken, on our large wire in front of ns2 the
Cisco 2 years ago even killed zone transfers at least from
"large" zones at all as well as PTR answers from the NAT behind
containing the public IP
thanks and sorry for the noise
i start now in case of any technical problem to consult my ISP
because 98 out of 100 cases are their settings and changes
[harry at srv-rhsoft:~]$ dig www.rhsoft.net @ns1.thelounge.net
;; ANSWER SECTION:
www.rhsoft.net. 86400 IN CNAME proxy.thelounge.net.
proxy.thelounge.net. 86400 IN A 91.118.73.4
;; Query time: 23 msec
;; SERVER: 85.124.176.242#53(85.124.176.242)
;; WHEN: Do Jun 05 20:15:13 CEST 2014
;; MSG SIZE rcvd: 89
[harry at srv-rhsoft:~]$ dig www.rhsoft.net @ns2.thelounge.net
;; ANSWER SECTION:
www.rhsoft.net. 86400 IN CNAME proxy.thelounge.net.
proxy.thelounge.net. 86400 IN A 91.118.73.4
;; Query time: 14 msec
;; SERVER: 91.118.73.16#53(91.118.73.16)
;; WHEN: Do Jun 05 20:15:17 CEST 2014
;; MSG SIZE rcvd: 89
> On Jun 5, 2014 12:43 PM, "Reindl Harald" <h.reindl at thelounge.net <mailto:h.reindl at thelounge.net>> wrote:
> Am 05.06.2014 17:58, schrieb /dev/rob0:
> > On Thu, Jun 05, 2014 at 05:21:47PM +0200, Reindl Harald wrote:
> >> what the hell invents "$TTL 0 ; 0 seconds" lines before
> >> each CNAME block while on the master there is exactly
> >> one TTL line with 86400 on top of the file?
> >
> > The way named writes a zone file is not the way I would do it.
> > Records are strictly in alphabetic order, and $TTL blocks are made
> > around all RRSETs where TTL varies.
> >
> > The zone FILE is not your problem. I don't know exactly what the
> > problem might be. It seems that something is intercepting and
> > filtering the zone transfers?
> >
> > You could try transfers manually from the slave:
> >
> > dig [key auth if required] rhsoft.net <http://rhsoft.net>. axfr @91.118.73.16 <http://91.118.73.16>
> >
> > Does that show any zero TTLs? If so I suggest you place a couple of
> > sniffers at strategic spots, one leaving the master, another entering
> > the slave, and force a zone transfer.
>
> as yolu can see clearly below any CNAME record comes with a zero TTL
> the dotted line are a lot of CNAMES, all with zero TTL
> after them the first A-record has again the desired 86400
>
> the SOA at the end comes also with 86400 and the CNAME
> block before again has a TTL of zero
>
> i can't imagine anyhting which would sit between the
> transfer and change things - aaaah wait there was a
> Zyxel router in front of ns1 which was exploitable
> and now is replaced by a small Cisco from the ISP
>
> oh, no, don't tell me that my ISP clutters DNS again :-(
>
> [root at ns2:~]$ dig rhsoft.net <http://rhsoft.net>. axfr @91.118.73.16 <http://91.118.73.16>
>
> ; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-15.P2.fc19 <<>> rhsoft.net <http://rhsoft.net>. axfr @91.118.73.16
> <http://91.118.73.16>
> ;; global options: +cmd
> rhsoft.net <http://rhsoft.net>. 86400 IN SOA ns2.thelounge.net
> <http://ns2.thelounge.net>. hostmaster.thelounge.net <http://hostmaster.thelounge.net>. 1226095186 3600 1800
> 1814400 3600 <tel:1814400%203600>
> rhsoft.net <http://rhsoft.net>. 86400 IN MX 10 barracuda.thelounge.net
> <http://barracuda.thelounge.net>.
> rhsoft.net <http://rhsoft.net>. 86400 IN TXT "v=spf1 ip4:91.118.73.0/24
> <http://91.118.73.0/24> ip4:89.207.144.27 ip4:62.178.103.85 -all"
> rhsoft.net <http://rhsoft.net>. 86400 IN SPF "v=spf1 ip4:91.118.73.0/24
> <http://91.118.73.0/24> ip4:89.207.144.27 ip4:62.178.103.85 -all"
> rhsoft.net <http://rhsoft.net>. 86400 IN NS ns2.thelounge.net <http://ns2.thelounge.net>.
> rhsoft.net <http://rhsoft.net>. 86400 IN NS ns1.thelounge.net <http://ns1.thelounge.net>.
> rhsoft.net <http://rhsoft.net>. 86400 IN A 91.118.73.4
> **.rhsoft.net <http://rhsoft.net>. 0 IN CNAME **.rhsoft.net <http://rhsoft.net>.
> **.rhsoft.net <http://rhsoft.net>. 0 IN CNAME **.rhsoft.net <http://rhsoft.net>.
> ................................
> testserver.rhsoft.net <http://testserver.rhsoft.net>. 86400 IN A 84.113.92.77
> **.rhsoft.net <http://rhsoft.net>. 0 IN CNAME **.rhsoft.net <http://rhsoft.net>.
> rhsoft.net <http://rhsoft.net>. 86400 IN SOA ns2.thelounge.net
> <http://ns2.thelounge.net>. hostmaster.thelounge.net <http://hostmaster.thelounge.net>. 1226095186 3600 1800
> 1814400 3600 <tel:1814400%203600>
> ;; Query time: 22 msec
> ;; SERVER: 91.118.73.16#53(91.118.73.16)
> ;; WHEN: Do Jun 05 18:35:08 CEST 2014
> ;; XFR size: 58 records (messages 1, bytes 1545)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140605/7d18b6c1/attachment.bin>
More information about the bind-users
mailing list