Slave zero-TTL on CNAMES

[Ben Croswell]

Cisco routers do have the ability to "doctor" DNS packets when doing NAT.
When it doctors it sets the TTL to 0 but I dont know why it would only do
it on CNAME records.
On Jun 5, 2014 12:43 PM, "Reindl Harald" <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. axfr @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. axfr @91.118.73.16
>
> ; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-15.P2.fc19 <<>> rhsoft.net.
> axfr @91.118.73.16
> ;; global options: +cmd
> rhsoft.net.             86400   IN      SOA     ns2.thelounge.net.
> hostmaster.thelounge.net. 1226095186 3600 1800
> 1814400 3600
> rhsoft.net.             86400   IN      MX      10 barracuda.thelounge.net
> .
> rhsoft.net.             86400   IN      TXT     "v=spf1 ip4:91.118.73.0/24
> ip4:89.207.144.27 ip4:62.178.103.85 -all"
> rhsoft.net.             86400   IN      SPF     "v=spf1 ip4:91.118.73.0/24
> ip4:89.207.144.27 ip4:62.178.103.85 -all"
> rhsoft.net.             86400   IN      NS      ns2.thelounge.net.
> rhsoft.net.             86400   IN      NS      ns1.thelounge.net.
> rhsoft.net.             86400   IN      A       91.118.73.4
> **.rhsoft.net.          0       IN      CNAME   **.rhsoft.net.
> **.rhsoft.net.          0       IN      CNAME   **.rhsoft.net.
> ................................
> testserver.rhsoft.net.  86400   IN      A       84.113.92.77
> **.rhsoft.net.          0       IN      CNAME   **.rhsoft.net.
> rhsoft.net.             86400   IN      SOA     ns2.thelounge.net.
> hostmaster.thelounge.net. 1226095186 3600 1800
> 1814400 3600
> ;; 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)
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140605/1098caa2/attachment.html>