Re: Slave zero-TTL on CNAMES
uhm - look at the bottom - *they have* a zero TTL after named-compilezone Am 05.06.2014 16:48, schrieb Reindl Harald: Hi how is that below possible? * ns2.thelounge.net = Master * ns1.thelounge.net = Slave * both are using the same packages (VMwware clones) * i removed the zone file on the slave and restarted named * the zone was transferred for sure again with that new binary format * that affactes *any* zone on that both servers how can the slave give a different answer [root@ns1:~]$ rpm -qa | grep bind bind-license-9.9.3-15.P2.fc19.noarch bind-9.9.3-15.P2.fc19.x86_64 bind-utils-9.9.3-15.P2.fc19.x86_64 bind-chroot-9.9.3-15.P2.fc19.x86_64 bind-libs-9.9.3-15.P2.fc19.x86_64 bind-libs-lite-9.9.3-15.P2.fc19.x86_64 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns1.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns1.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54655 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 0 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 19 msec ;; SERVER: 85.124.176.242#53(85.124.176.242) ;; WHEN: Do Jun 05 16:43:38 CEST 2014 ;; MSG SIZE rcvd: 89 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns2.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns2.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2758 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 86400 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 12 msec ;; SERVER: 91.118.73.16#53(91.118.73.16) ;; WHEN: Do Jun 05 16:43:41 CEST 2014 ;; MSG SIZE rcvd: 89 [root@ns1:~]$ named-compilezone -f raw -F text -o /var/named/chroot/var/named/slaves/rhsoft.net.dns rhsoft.net /var/named/chroot/var/named/slaves/rhsoft.net.dns zone rhsoft.net/IN: loaded serial 1226095186 dump zone to /var/named/chroot/var/named/slaves/rhsoft.net.dns...done OK [root@asterisk:~]$ cat /var/named/chroot/var/named/slaves/rhsoft.net.dns rhsoft.net. 86400 IN SOA ns2.thelounge.net. hostmaster.thelounge.net. 1226095186 3600 1800 1814400 3600 rhsoft.net. 86400 IN NS ns2.thelounge.net. rhsoft.net. 86400 IN NS ns1.thelounge.net. rhsoft.net. 86400 IN A91.118.73.4 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 www.rhsoft.net. 0 IN CNAME proxy.thelounge.net. signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zero-TTL on CNAMES
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? _ master-zone: [root@ns2:~]$ cat /var/named/chroot/var/named/zones/rhsoft.net.dns | grep TTL $TTL 86400 3600; Negative-TTL [root@ns2:~]$ cat /var/named/chroot/var/named/zones/rhsoft.net.dns | grep TTL | wc -l 2 _ slave: [root@ns1:~]$ cat /var/named/chroot/var/named/slaves/rhsoft.net.dns | grep TTL $TTL 86400 ; 1 day $TTL 0 ; 0 seconds $TTL 86400 ; 1 day $TTL 0 ; 0 seconds $TTL 86400 ; 1 day $TTL 0 ; 0 seconds $TTL 86400 ; 1 day $TTL 0 ; 0 seconds [root@ns1:~]$ cat /var/named/chroot/var/named/slaves/rhsoft.net.dns $ORIGIN . $TTL 86400 ; 1 day rhsoft.net IN SOA ns2.thelounge.net. hostmaster.thelounge.net. ( 1226095186 ; serial 3600 ; refresh (1 hour) 1800 ; retry (30 minutes) 1814400; expire (3 weeks) 3600 ; minimum (1 hour) ) NS ns2.thelounge.net. NS ns1.thelounge.net. A 91.118.73.4 MX 10 barracuda.thelounge.net. TXT v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all SPF v=spf1 ip4:91.118.73.0/24 ip4:89.207.144.27 ip4:62.178.103.85 -all $ORIGIN rhsoft.net. $TTL 0 ; 0 seconds autoconfig CNAME autoconfig.thelounge.net. autodiscoverCNAME autodiscover-non-tls.thelounge.net. Am 05.06.2014 17:02, schrieb Reindl Harald: uhm - look at the bottom - *they have* a zero TTL after named-compilezone Am 05.06.2014 16:48, schrieb Reindl Harald: Hi how is that below possible? * ns2.thelounge.net = Master * ns1.thelounge.net = Slave * both are using the same packages (VMwware clones) * i removed the zone file on the slave and restarted named * the zone was transferred for sure again with that new binary format * that affactes *any* zone on that both servers how can the slave give a different answer [root@ns1:~]$ rpm -qa | grep bind bind-license-9.9.3-15.P2.fc19.noarch bind-9.9.3-15.P2.fc19.x86_64 bind-utils-9.9.3-15.P2.fc19.x86_64 bind-chroot-9.9.3-15.P2.fc19.x86_64 bind-libs-9.9.3-15.P2.fc19.x86_64 bind-libs-lite-9.9.3-15.P2.fc19.x86_64 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns1.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns1.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54655 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 0 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 19 msec ;; SERVER: 85.124.176.242#53(85.124.176.242) ;; WHEN: Do Jun 05 16:43:38 CEST 2014 ;; MSG SIZE rcvd: 89 __ [harry@srv-rhsoft:~]$ dig www.rhsoft.net @ns2.thelounge.net ; DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 www.rhsoft.net @ns2.thelounge.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 2758 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 3072 ;; QUESTION SECTION: ;www.rhsoft.net.IN A ;; ANSWER SECTION: www.rhsoft.net. 86400 IN CNAME proxy.thelounge.net. proxy.thelounge.net.86400 IN A 91.118.73.4 ;; Query time: 12 msec ;; SERVER: 91.118.73.16#53(91.118.73.16) ;; WHEN: Do Jun 05 16:43:41 CEST 2014 ;; MSG SIZE rcvd: 89 [root@ns1:~]$ named-compilezone -f raw -F text -o /var/named/chroot/var/named/slaves/rhsoft.net.dns rhsoft.net /var/named/chroot/var/named/slaves/rhsoft.net.dns zone rhsoft.net/IN: loaded serial 1226095186 dump zone to /var/named/chroot/var/named/slaves/rhsoft.net.dns...done OK [root@asterisk:~]$ cat /var/named/chroot/var/named/slaves/rhsoft.net.dns rhsoft.net. 86400 IN SOA ns2.thelounge.net. hostmaster.thelounge.net. 1226095186 3600 1800 1814400 3600 rhsoft.net. 86400 IN NS ns2.thelounge.net. rhsoft.net. 86400 IN NS
Re: Slave zero-TTL on CNAMES
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. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zero-TTL on CNAMES
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 - h 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@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) signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zero-TTL on CNAMES
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.rei...@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 - h 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@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@lists.isc.org 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 bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zero-TTL on CNAMES - no ip nat service alg udp dns
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@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@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.rei...@thelounge.net mailto:h.rei...@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 - h 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@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.
