From keith at dns-oarc.net Thu Oct 1 19:06:50 2015 From: keith at dns-oarc.net (Keith Mitchell) Date: Thu, 01 Oct 2015 15:06:50 -0400 Subject: [dns-operations] DNS-OARC Fall 2015 Workshop - Final Information In-Reply-To: <54233571.3020004@dns-oarc.net> References: <53FE3428.4040907@dns-oarc.net> <54233571.3020004@dns-oarc.net> Message-ID: <560D844A.6060005@dns-oarc.net> A final reminder that DNS-OARC's 2015 Spring Workshop will be taking place *this* weekend in Montreal. Our agenda is now finalized and very full of great quality content, at: https://indico.dns-oarc.net/event/24/timetable/#all.detailed The workshop kicks off with the OARC AGM and business session from 10:00 to 12:30 EDT on Saturday 3rd. The main workshop starts at 14:00 on Saturday, running until 17:45 Sunday 4th. All proceedings will be webcast and open to all who register. If you did not already register, we still have space, you can do so at: https://indico.dns-oarc.net/event/24/ Saturday evening we have a social event for registered attendees from 18:00 at a nearby bar. Our thanks to CIRA for sponsoring this event. Remote participation will be supported, using Google Hangouts, you can view the webcast at: https://plus.google.com/+DnsoarcNetPlus/ with slides linked to from the above meeting timetable page, and OARC's Jabber room: xmpp://dns-operations at conference.dns-oarc.net You can find full information about the workshop at: https://indico.dns-oarc.net/event/24/ Note that we are regrettably unable to accept any last-minute submissions or lighting talks, unless there are any speaker cancellations. Finally, a big Thank You to our sponsors: * CIRA: Gold & Social * Nominum: Bronze and to NANOG for their help with connectivity and venue logistics. Keith Mitchell OARC President From ondrej.sury at nic.cz Sun Oct 4 10:59:51 2015 From: ondrej.sury at nic.cz (=?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Sun, 4 Oct 2015 12:59:51 +0200 (CEST) Subject: [dns-operations] FYI: DNS test harness Message-ID: <18630316.14356.1443956391762.JavaMail.zimbra@nic.cz> Hi, a follow up on the functional testing: We have produced DNS test harness on top of socket_wrapper and libfaketime in a process of building and testing our own Knot DNS Resolver and here are some thoughts on that: https://storify.com/KnotDNS/deckard-a-dns-software-test-harness We would love to have a feedback on this project from other DNS server vendors. O. -- Ond?ej Sur? -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato?e CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.sury at nic.cz https://nic.cz/ -------------------------------------------- From frnkblk at iname.com Mon Oct 5 22:15:34 2015 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 5 Oct 2015 17:15:34 -0500 Subject: [dns-operations] Second set of eyes on www.brocade.com or lldns.net Message-ID: <002601d0ffbb$5b1c8f70$1155ae50$@iname.com> My monitoring of HTTPv6 access to http://www.brocade.com has been showing the site to go up and down. Further investigation revealed that our monitoring server is regularly not getting any AAAA for www.brocade.com. Several times over the weekend I checked all our DNS servers (three corporate on Windows, two upstream, and seven ISP on ISC) and it's just two of our ISP servers are showing this symptom. www.brocade.com has a CNAME to brocade.cust.lldns.net (LimeLight, a CDN Brocade's website recently moved to), and that always works, but the CNAME doesn't always return the AAAA. Note that the A always returns. I checked both www.brocade.com and brocade.cust.lldns.net against a few DNS checking sites, but nothing popped up. Am hitting perhaps a faulty DNS server behind a load-balancer at ns1.lldns.net and ns2.lldns.net, and our two server IPs are hashed to use that from time to time? Any other ideas? ============================================ DNS server: 96.31.0.5 ; <<>> DiG 9.7.3 <<>> AAAA www.brocade.com @96.31.0.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10727 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.brocade.com. IN AAAA ;; ANSWER SECTION: www.brocade.com. 274 IN CNAME brocade.cust.lldns.net. ;; AUTHORITY SECTION: lldns.net. 2794 IN SOA lldns.net. root.lldns.net. 2010041901 600 300 604800 10 ;; Query time: 0 msec ;; SERVER: 96.31.0.5#53(96.31.0.5) ;; WHEN: Mon Oct 5 17:10:50 2015 ;; MSG SIZE rcvd: 110 ============================================ DNS server: 96.31.0.8 ; <<>> DiG 9.7.3 <<>> AAAA www.brocade.com @96.31.0.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1753 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.brocade.com. IN AAAA ;; ANSWER SECTION: www.brocade.com. 826 IN CNAME brocade.cust.lldns.net. ;; AUTHORITY SECTION: lldns.net. 3582 IN SOA lldns.net. root.lldns.net. 2010041901 600 300 604800 10 ;; Query time: 0 msec ;; SERVER: 96.31.0.8#53(96.31.0.8) ;; WHEN: Mon Oct 5 17:10:50 2015 ;; MSG SIZE rcvd: 110 ============================================ DNS server: 96.31.0.5 ; <<>> DiG 9.7.3 <<>> AAAA brocade.cust.lldns.net @96.31.0.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10590 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;brocade.cust.lldns.net. IN AAAA ;; AUTHORITY SECTION: lldns.net. 2744 IN SOA lldns.net. root.lldns.net. 2010041901 600 300 604800 10 ;; Query time: 0 msec ;; SERVER: 96.31.0.5#53(96.31.0.5) ;; WHEN: Mon Oct 5 17:11:40 2015 ;; MSG SIZE rcvd: 81 ============================================ DNS server: 96.31.0.8 ; <<>> DiG 9.7.3 <<>> AAAA brocade.cust.lldns.net @96.31.0.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40126 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;brocade.cust.lldns.net. IN AAAA ;; AUTHORITY SECTION: lldns.net. 3532 IN SOA lldns.net. root.lldns.net. 2010041901 600 300 604800 10 ;; Query time: 0 msec ;; SERVER: 96.31.0.8#53(96.31.0.8) ;; WHEN: Mon Oct 5 17:11:40 2015 ;; MSG SIZE rcvd: 81 ============================================ From frnkblk at iname.com Wed Oct 7 04:05:49 2015 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 6 Oct 2015 23:05:49 -0500 Subject: [dns-operations] Second set of eyes on www.brocade.com or lldns.net In-Reply-To: <002601d0ffbb$5b1c8f70$1155ae50$@iname.com> References: <002601d0ffbb$5b1c8f70$1155ae50$@iname.com> Message-ID: <001801d100b5$73968560$5ac39020$@iname.com> FYI, someone from LimeLight Networks contacted me off list and opened a ticket internally. 25 hours later the issue was resolved, though I don't know what it was that LL found. Thanks, Frank -----Original Message----- From: dns-operations [mailto:dns-operations-bounces at dns-oarc.net] On Behalf Of Frank Bulk Sent: Monday, October 05, 2015 5:16 PM To: dns-operations at dns-oarc.net Subject: [dns-operations] Second set of eyes on www.brocade.com or lldns.net My monitoring of HTTPv6 access to http://www.brocade.com has been showing the site to go up and down. Further investigation revealed that our monitoring server is regularly not getting any AAAA for www.brocade.com. Several times over the weekend I checked all our DNS servers (three corporate on Windows, two upstream, and seven ISP on ISC) and it's just two of our ISP servers are showing this symptom. www.brocade.com has a CNAME to brocade.cust.lldns.net (LimeLight, a CDN Brocade's website recently moved to), and that always works, but the CNAME doesn't always return the AAAA. Note that the A always returns. I checked both www.brocade.com and brocade.cust.lldns.net against a few DNS checking sites, but nothing popped up. Am hitting perhaps a faulty DNS server behind a load-balancer at ns1.lldns.net and ns2.lldns.net, and our two server IPs are hashed to use that from time to time? Any other ideas? ============================================ DNS server: 96.31.0.5 ; <<>> DiG 9.7.3 <<>> AAAA www.brocade.com @96.31.0.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10727 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.brocade.com. IN AAAA ;; ANSWER SECTION: www.brocade.com. 274 IN CNAME brocade.cust.lldns.net. ;; AUTHORITY SECTION: lldns.net. 2794 IN SOA lldns.net. root.lldns.net. 2010041901 600 300 604800 10 ;; Query time: 0 msec ;; SERVER: 96.31.0.5#53(96.31.0.5) ;; WHEN: Mon Oct 5 17:10:50 2015 ;; MSG SIZE rcvd: 110 ============================================ DNS server: 96.31.0.8 ; <<>> DiG 9.7.3 <<>> AAAA www.brocade.com @96.31.0.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1753 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.brocade.com. IN AAAA ;; ANSWER SECTION: www.brocade.com. 826 IN CNAME brocade.cust.lldns.net. ;; AUTHORITY SECTION: lldns.net. 3582 IN SOA lldns.net. root.lldns.net. 2010041901 600 300 604800 10 ;; Query time: 0 msec ;; SERVER: 96.31.0.8#53(96.31.0.8) ;; WHEN: Mon Oct 5 17:10:50 2015 ;; MSG SIZE rcvd: 110 ============================================ DNS server: 96.31.0.5 ; <<>> DiG 9.7.3 <<>> AAAA brocade.cust.lldns.net @96.31.0.5 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10590 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;brocade.cust.lldns.net. IN AAAA ;; AUTHORITY SECTION: lldns.net. 2744 IN SOA lldns.net. root.lldns.net. 2010041901 600 300 604800 10 ;; Query time: 0 msec ;; SERVER: 96.31.0.5#53(96.31.0.5) ;; WHEN: Mon Oct 5 17:11:40 2015 ;; MSG SIZE rcvd: 81 ============================================ DNS server: 96.31.0.8 ; <<>> DiG 9.7.3 <<>> AAAA brocade.cust.lldns.net @96.31.0.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40126 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;brocade.cust.lldns.net. IN AAAA ;; AUTHORITY SECTION: lldns.net. 3532 IN SOA lldns.net. root.lldns.net. 2010041901 600 300 604800 10 ;; Query time: 0 msec ;; SERVER: 96.31.0.8#53(96.31.0.8) ;; WHEN: Mon Oct 5 17:11:40 2015 ;; MSG SIZE rcvd: 81 ============================================ _______________________________________________ dns-operations mailing list dns-operations at lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs From bortzmeyer at nic.fr Fri Oct 9 10:22:04 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 9 Oct 2015 12:22:04 +0200 Subject: [dns-operations] Funny DNSSEC problem In-Reply-To: <20150407193703.GA32176@sources.org> References: <20150407193703.GA32176@sources.org> Message-ID: <20151009102204.GA29902@nic.fr> On Tue, Apr 07, 2015 at 09:37:03PM +0200, Stephane Bortzmeyer wrote a message of 191 lines which said: > The domain juralib.nologs.org does not resolve (SERVFAIL) from Free > (2nd ISP in France, uses DNSSEC validation). After a long time, I think I've found the cause: Free's DNS resolvers drop the NSEC3 record. Since the zone uses wildcards (the number of labels in the signature is 2, not 3, showing there is a wilcard), the resolver wants to check that the name does not exist and was indeed synthetized through the wildcard, but it fails to find the NSEC and booom. As, for the root cause (why dropping the NSEC3 record?), I don't know but I suspect it is a consequence of the other problem, multiplying the CNAME record: not enough room in the answer, records dropped. The reply, with the multiple CNAMEs and the missing NSEC3 (the correct reply follow). >From Free : % dig +cd ladiscordia.noblogs.org ; <<>> DiG 9.10.2-P2 <<>> +cd ladiscordia.noblogs.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16475 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 15, AUTHORITY: 5, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;ladiscordia.noblogs.org. IN A ;; ANSWER SECTION: ladiscordia.noblogs.org. 2284 IN CNAME www.l.autistici.org. ladiscordia.noblogs.org. 2284 IN RRSIG CNAME 7 2 9600 ( 20151101063004 20151002063004 64367 noblogs.org. LuRSXa97Yjr+wYVGjq8yFxIOTXeufRMNaL6L31jqq3im MphTYlJRGvwTzZTPwbbbkZjSuCtt5P7l3/iMx50ZEZ/B x3q0PDD3Yo4ckrfcIzMQ9V+HeosW+W78UBTC0LyQIxSq eRdlhsNZKSELmR8k9sVpJ5mrQPTQ3HzGzUr4z1w= ) ladiscordia.noblogs.org. 2284 IN CNAME www.l.autistici.org. ladiscordia.noblogs.org. 2284 IN RRSIG CNAME 7 2 9600 ( 20151101063004 20151002063004 64367 noblogs.org. LuRSXa97Yjr+wYVGjq8yFxIOTXeufRMNaL6L31jqq3im MphTYlJRGvwTzZTPwbbbkZjSuCtt5P7l3/iMx50ZEZ/B x3q0PDD3Yo4ckrfcIzMQ9V+HeosW+W78UBTC0LyQIxSq eRdlhsNZKSELmR8k9sVpJ5mrQPTQ3HzGzUr4z1w= ) ladiscordia.noblogs.org. 2284 IN CNAME www.l.autistici.org. ladiscordia.noblogs.org. 2284 IN RRSIG CNAME 7 2 9600 ( 20151101063004 20151002063004 64367 noblogs.org. LuRSXa97Yjr+wYVGjq8yFxIOTXeufRMNaL6L31jqq3im MphTYlJRGvwTzZTPwbbbkZjSuCtt5P7l3/iMx50ZEZ/B x3q0PDD3Yo4ckrfcIzMQ9V+HeosW+W78UBTC0LyQIxSq eRdlhsNZKSELmR8k9sVpJ5mrQPTQ3HzGzUr4z1w= ) ladiscordia.noblogs.org. 2284 IN CNAME www.l.autistici.org. ladiscordia.noblogs.org. 2284 IN RRSIG CNAME 7 2 9600 ( 20151101063004 20151002063004 64367 noblogs.org. LuRSXa97Yjr+wYVGjq8yFxIOTXeufRMNaL6L31jqq3im MphTYlJRGvwTzZTPwbbbkZjSuCtt5P7l3/iMx50ZEZ/B x3q0PDD3Yo4ckrfcIzMQ9V+HeosW+W78UBTC0LyQIxSq eRdlhsNZKSELmR8k9sVpJ5mrQPTQ3HzGzUr4z1w= ) ladiscordia.noblogs.org. 2284 IN CNAME www.l.autistici.org. ladiscordia.noblogs.org. 2284 IN RRSIG CNAME 7 2 9600 ( 20151101063004 20151002063004 64367 noblogs.org. LuRSXa97Yjr+wYVGjq8yFxIOTXeufRMNaL6L31jqq3im MphTYlJRGvwTzZTPwbbbkZjSuCtt5P7l3/iMx50ZEZ/B x3q0PDD3Yo4ckrfcIzMQ9V+HeosW+W78UBTC0LyQIxSq eRdlhsNZKSELmR8k9sVpJ5mrQPTQ3HzGzUr4z1w= ) ladiscordia.noblogs.org. 2284 IN CNAME www.l.autistici.org. ladiscordia.noblogs.org. 2284 IN RRSIG CNAME 7 2 9600 ( 20151101063004 20151002063004 64367 noblogs.org. LuRSXa97Yjr+wYVGjq8yFxIOTXeufRMNaL6L31jqq3im MphTYlJRGvwTzZTPwbbbkZjSuCtt5P7l3/iMx50ZEZ/B x3q0PDD3Yo4ckrfcIzMQ9V+HeosW+W78UBTC0LyQIxSq eRdlhsNZKSELmR8k9sVpJ5mrQPTQ3HzGzUr4z1w= ) www.l.autistici.org. 1800 IN A 94.23.50.208 www.l.autistici.org. 1800 IN A 82.94.249.234 www.l.autistici.org. 1800 IN RRSIG A 7 4 30 ( 20151105063002 20151006063002 2207 l.autistici.org. HDkkzb8afOIlk5P0HRmiVal7KmAu4bevmkAPpHuAMruS 9Pj2OkWjeWwJiLm7zX5MjqIcfUBvJ6gbODvRGr7dDJHn 7qqLNA3IXMvxm5trBWz2/YZsTs/2XEgIBDVgxRel+OBp HD+riKX0ZylmTGXG7/fyRfcYLquwphS4gNTMWbk= ) ;; AUTHORITY SECTION: l.autistici.org. 1800 IN NS ns1.investici.org. l.autistici.org. 1800 IN NS ns2.investici.org. l.autistici.org. 1800 IN NS ns2-v6.investici.org. l.autistici.org. 1800 IN NS ns1-v6.investici.org. l.autistici.org. 1800 IN RRSIG NS 7 3 30 ( 20151105063002 20151006063002 2207 l.autistici.org. bA28B6AP9NQzyavLXFZoxDCsV1kDpZwid+QyPcR2qhrj c3wfuB6P2PM7WBHzlbZevt1C3+z/FMqvXRr/TrhbseDy ScKCai/LPD68z0bqUucz0uuFbDpTxvJNDf+0zJrMQTsw +zse/UsiopBVrqCjOXRWte2DvDxyCPtN3WnEYJc= ) ;; Query time: 26 msec ;; SERVER: 192.168.2.254#53(192.168.2.254) ;; WHEN: Fri Oct 09 11:09:32 CEST 2015 ;; MSG SIZE rcvd: 1648 >From elsewhere: % dig ladiscordia.noblogs.org ; <<>> DiG 9.9.5-9+deb8u3-Debian <<>> ladiscordia.noblogs.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21826 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 7, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;ladiscordia.noblogs.org. IN A ;; ANSWER SECTION: ladiscordia.noblogs.org. 9599 IN CNAME www.l.autistici.org. ladiscordia.noblogs.org. 9599 IN RRSIG CNAME 7 2 9600 ( 20151101063004 20151002063004 64367 noblogs.org. LuRSXa97Yjr+wYVGjq8yFxIOTXeufRMNaL6L31jqq3im MphTYlJRGvwTzZTPwbbbkZjSuCtt5P7l3/iMx50ZEZ/B x3q0PDD3Yo4ckrfcIzMQ9V+HeosW+W78UBTC0LyQIxSq eRdlhsNZKSELmR8k9sVpJ5mrQPTQ3HzGzUr4z1w= ) www.l.autistici.org. 30 IN A 94.23.50.208 www.l.autistici.org. 30 IN A 82.94.249.234 www.l.autistici.org. 30 IN RRSIG A 7 4 30 ( 20151105063002 20151006063002 2207 l.autistici.org. HDkkzb8afOIlk5P0HRmiVal7KmAu4bevmkAPpHuAMruS 9Pj2OkWjeWwJiLm7zX5MjqIcfUBvJ6gbODvRGr7dDJHn 7qqLNA3IXMvxm5trBWz2/YZsTs/2XEgIBDVgxRel+OBp HD+riKX0ZylmTGXG7/fyRfcYLquwphS4gNTMWbk= ) ;; AUTHORITY SECTION: EDG28OM0KF8LV6JVVTUAE9R7GLNTNKMD.noblogs.org. 3599 IN NSEC3 1 0 10 5CA1AB1E ( K1C26GO8L9TJ398E8MKH7QLSP4LB88UO CNAME RRSIG ) EDG28OM0KF8LV6JVVTUAE9R7GLNTNKMD.noblogs.org. 3599 IN RRSIG NSEC3 7 3 3600 ( 20151101063004 20151002063004 64367 noblogs.org. juTchEjZZFdj5WkhyKh/2qZxffIjahcjtWrC7aiM78QT nuBLP6AqRatIwpbIauM9ZbBwXD1ZXwRhpZrLTDKqS8bK qU5dsUCKsB3vIYba84I12t1bAg0YKv0HP8bkEMp9ftO+ bZNLtY+TXyaZ5FULNI26gMen2YYsqPovY0YnH0M= ) l.autistici.org. 30 IN NS ns2.investici.org. l.autistici.org. 30 IN NS ns2-v6.investici.org. l.autistici.org. 30 IN NS ns1-v6.investici.org. l.autistici.org. 30 IN NS ns1.investici.org. l.autistici.org. 30 IN RRSIG NS 7 3 30 ( 20151105063002 20151006063002 2207 l.autistici.org. bA28B6AP9NQzyavLXFZoxDCsV1kDpZwid+QyPcR2qhrj c3wfuB6P2PM7WBHzlbZevt1C3+z/FMqvXRr/TrhbseDy ScKCai/LPD68z0bqUucz0uuFbDpTxvJNDf+0zJrMQTsw +zse/UsiopBVrqCjOXRWte2DvDxyCPtN3WnEYJc= ) ;; Query time: 1207 msec ;; SERVER: ::1#53(::1) ;; WHEN: Fri Oct 09 10:13:25 CEST 2015 ;; MSG SIZE rcvd: 977 From rvandolson at esri.com Mon Oct 12 14:31:47 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Mon, 12 Oct 2015 07:31:47 -0700 Subject: [dns-operations] DNS Hosting and Logging Message-ID: <20151012143146.GA1183@esri.com> Hi, everyone... Anyone aware of DNS hosting services which provide query log access (either via tunneled syslog or API)? Thinking EasyDns may do something. Doesn't appear Route 53 does. For those of you in the Enterprise space, do you find value in having at least partial visibility into detailed information on external queries? Ray From jdevasia at akamai.com Mon Oct 12 15:05:04 2015 From: jdevasia at akamai.com (Devasia, John) Date: Mon, 12 Oct 2015 15:05:04 +0000 Subject: [dns-operations] DNS Hosting and Logging In-Reply-To: <20151012143146.GA1183@esri.com> References: <20151012143146.GA1183@esri.com> Message-ID: Ray, Akamai?s Fast DNS does allow you access to logs for all requests Thanks JD On 10/12/15, 10:31 AM, "Ray Van Dolson" wrote: >Hi, everyone... > >Anyone aware of DNS hosting services which provide query log access >(either via tunneled syslog or API)? Thinking EasyDns may do >something. Doesn't appear Route 53 does. > >For those of you in the Enterprise space, do you find value in having >at least partial visibility into detailed information on external >queries? > >Ray >_______________________________________________ >dns-operations mailing list >dns-operations at lists.dns-oarc.net >https://lists.dns-oarc.net/mailman/listinfo/dns-operations >dns-jobs mailing list >https://lists.dns-oarc.net/mailman/listinfo/dns-jobs From graham.hayes at hpe.com Mon Oct 12 15:26:04 2015 From: graham.hayes at hpe.com (Hayes, Graham) Date: Mon, 12 Oct 2015 15:26:04 +0000 Subject: [dns-operations] DNS Hosting and Logging References: <20151012143146.GA1183@esri.com> Message-ID: <325F898546FBBF4487D24D6D606A277E18B57257@G4W3202.americas.hpqcorp.net> To slightly hi-jack the thread - is this something people are interested in? In OpenStack Designate we have not implemented this, as we were not sure how useful it would be, but if there is a need for it, we could look at adding it. Graham On 12/10/15 16:14, Devasia, John wrote: > Ray, > > Akamai?s Fast DNS does allow you access to logs for all requests > > Thanks > JD > > On 10/12/15, 10:31 AM, "Ray Van Dolson" wrote: > >> Hi, everyone... >> >> Anyone aware of DNS hosting services which provide query log access >> (either via tunneled syslog or API)? Thinking EasyDns may do >> something. Doesn't appear Route 53 does. >> >> For those of you in the Enterprise space, do you find value in having >> at least partial visibility into detailed information on external >> queries? >> >> Ray >> _______________________________________________ >> dns-operations mailing list >> dns-operations at lists.dns-oarc.net >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >> dns-jobs mailing list >> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs > > > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs > From rvandolson at esri.com Mon Oct 12 15:33:44 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Mon, 12 Oct 2015 08:33:44 -0700 Subject: [dns-operations] DNS Hosting and Logging In-Reply-To: <325F898546FBBF4487D24D6D606A277E18B57257@G4W3202.americas.hpqcorp.net> References: <20151012143146.GA1183@esri.com> <325F898546FBBF4487D24D6D606A277E18B57257@G4W3202.americas.hpqcorp.net> Message-ID: <20151012153341.GA2557@esri.com> For some reason I didn't get JD's response directly. Fast DNS looks interesting -- know if it supports AXFR-based updates? Graham -- not using OpenStack, but definitely value in being able to retrieve query information (trends, troubleshooting). Ray On Mon, Oct 12, 2015 at 03:26:04PM +0000, Hayes, Graham wrote: > To slightly hi-jack the thread - is this something people are > interested in? > > In OpenStack Designate we have not implemented this, as we were not sure > how useful it would be, but if there is a need for it, we could look at > adding it. > > Graham > > On 12/10/15 16:14, Devasia, John wrote: > > Ray, > > > > Akamai?s Fast DNS does allow you access to logs for all requests > > > > Thanks > > JD > > > > On 10/12/15, 10:31 AM, "Ray Van Dolson" wrote: > > > >> Hi, everyone... > >> > >> Anyone aware of DNS hosting services which provide query log access > >> (either via tunneled syslog or API)? Thinking EasyDns may do > >> something. Doesn't appear Route 53 does. > >> > >> For those of you in the Enterprise space, do you find value in having > >> at least partial visibility into detailed information on external > >> queries? > >> > >> Ray From jabley at hopcount.ca Mon Oct 12 15:46:45 2015 From: jabley at hopcount.ca (Joe Abley) Date: Mon, 12 Oct 2015 11:46:45 -0400 Subject: [dns-operations] DNS Hosting and Logging In-Reply-To: <20151012143146.GA1183@esri.com> References: <20151012143146.GA1183@esri.com> Message-ID: Hi Ray, On 12 Oct 2015, at 10:31, Ray Van Dolson wrote: > Anyone aware of DNS hosting services which provide query log access > (either via tunneled syslog or API)? Thinking EasyDns may do > something. Doesn't appear Route 53 does. Dyn provides query logs to a number of customers. I'm not the person to talk to about the details, but I could hook you up if you were interested. Joe (works at Dyn) From rvandolson at esri.com Mon Oct 12 15:52:20 2015 From: rvandolson at esri.com (Ray Van Dolson) Date: Mon, 12 Oct 2015 08:52:20 -0700 Subject: [dns-operations] DNS Hosting and Logging In-Reply-To: References: <20151012143146.GA1183@esri.com> Message-ID: <20151012155219.GA2912@esri.com> On Mon, Oct 12, 2015 at 11:46:45AM -0400, Joe Abley wrote: > Hi Ray, > > On 12 Oct 2015, at 10:31, Ray Van Dolson wrote: > > >Anyone aware of DNS hosting services which provide query log access > >(either via tunneled syslog or API)? Thinking EasyDns may do > >something. Doesn't appear Route 53 does. > > Dyn provides query logs to a number of customers. I'm not the person > to talk to about the details, but I could hook you up if you were > interested. > > > Joe (works at Dyn) > Hi, Joe. Thanks, that'd be great. Exploring options at this point. Ray From m3047 at m3047.net Mon Oct 12 15:15:42 2015 From: m3047 at m3047.net (Fred Morris) Date: Mon, 12 Oct 2015 08:15:42 -0700 (GMT+7) Subject: [dns-operations] DNS Hosting and Logging In-Reply-To: <20151012143146.GA1183@esri.com> References: <20151012143146.GA1183@esri.com> Message-ID: On Mon, 12 Oct 2015, Ray Van Dolson wrote: > For those of you in the Enterprise space, do you find value in having > at least partial visibility into detailed information on external > queries? Anybody who's really serious about threat indicators should be watching DNS for anomalies ("full stack": not just what queries are we making, but where are those queries being directed). Having access to DNS logs is part of this: although one ought to be able to achieve a lot of it via DPI, it's often more efficient to be able to have the resolver logging this. Here is a one link... I'm sure you can find other articles out there. https://www.linkedin.com/pulse/dns-power-classification-lance-james -- Fred Morris From paul at redbarn.org Mon Oct 12 16:39:25 2015 From: paul at redbarn.org (Paul Vixie) Date: Mon, 12 Oct 2015 09:39:25 -0700 Subject: [dns-operations] DNS Hosting and Logging In-Reply-To: References: <20151012143146.GA1183@esri.com> Message-ID: <561BE23D.4090302@redbarn.org> Fred Morris wrote: > On Mon, 12 Oct 2015, Ray Van Dolson wrote: >> For those of you in the Enterprise space, do you find value in having >> at least partial visibility into detailed information on external >> queries? > > Anybody who's really serious about threat indicators should be watching > DNS for anomalies ("full stack": not just what queries are we making, but > where are those queries being directed). > > Having access to DNS logs is part of this: although one ought to be able > to achieve a lot of it via DPI, it's often more efficient to be able to > have the resolver logging this. this is the essence of passive dns, and i agree, but i think there's been an implicit thread fork. for authority dns (such as was asked about up-thread), query logs show inbound cache misses concerning the enterprise's own domain names. logs for this are available from some "secondary dns" providers but not all. for recursive dns (such as you are discussing here), query logs show both inbound queries from your stub clients (all your local file/web/other servers; all your local smartphone/tablet/labtop/desktop), and also outbound cache miss queries whenever a local stub wants something your local recursive server doesn't already know. this is "passive dns" as described first by florian weimer in his uni-stutgart thesis, "passive dns replication", and now a common practice in the internet security industry. -- Paul Vixie From songlinjian at gmail.com Tue Oct 13 08:14:31 2015 From: songlinjian at gmail.com (Davey Song) Date: Tue, 13 Oct 2015 16:14:31 +0800 Subject: [dns-operations] Yeti DNS Workshop 2015-10-31 (Pre-IETF 94) In-Reply-To: <147DB8C4-B247-47DD-A92D-AD6CD5819A89@gmail.com> References: <147DB8C4-B247-47DD-A92D-AD6CD5819A89@gmail.com> Message-ID: <0B0A389D-C688-4012-B465-FC41957BCD5A@gmail.com> An update for the Workshop (Time and Location confirmed!) Time: 13:00-17:00 , 31st, October (Saturday, one day before IETF) Location: Pacifico Yokohama, Meeting Room 514. Davey > ? 2015?8?14??18:33?Davey Song ??? > > Dear Colleagues, > > We are going to be holding a Yeti DNS workshop before IETF 94 in > Yokohama. > > Date: 2015-10-31 (Saturday before IETF 94) > Time: 10:00-16:00 (to be confirmed) > Location: Pacifico Yokohama (IETF venue, to be confirmed) > > It will be a half-day workshop, covering the status of the project at > that time. We expect reports on the project status from the > coordinators, discussion of experiments and other findings, as well as > both detailed and high-level plans. Topics outside of the Yeti DNS > project itself are also appropriate, if they are about related to the > work and future DNS Root service. A full agenda will be published in advance. > > RSVP: Please reply offline let us (coordinators at lists.yeti-dns.org ) know > if you are planning on attending. Also do please send any topic > suggestions or other proposals. > > Note that while this is Halloween, costumes are optional. > > --Yeti DNS project coordinators > > ------------------------------ > Davey Song(???) > BII Lab > songlinjian at gmail.com > > ------------------------------ Davey Song(???) BII Lab songlinjian at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tale at akamai.com Mon Oct 12 15:59:06 2015 From: tale at akamai.com (David C Lawrence) Date: Mon, 12 Oct 2015 11:59:06 -0400 Subject: [dns-operations] DNS Hosting and Logging In-Reply-To: <20151012153341.GA2557@esri.com> References: <20151012143146.GA1183@esri.com> <325F898546FBBF4487D24D6D606A277E18B57257@G4W3202.americas.hpqcorp.net> <20151012153341.GA2557@esri.com> Message-ID: <22043.55498.779535.975615@tale.kendall.corp.akamai.com> Ray Van Dolson writes: > For some reason I didn't get JD's response directly. Fast DNS looks > interesting -- know if it supports AXFR-based updates? It does, as a secondary. Akamai doesn't support AXFR to other servers. From wbrown at e1b.org Wed Oct 14 13:51:24 2015 From: wbrown at e1b.org (wbrown at e1b.org) Date: Wed, 14 Oct 2015 09:51:24 -0400 Subject: [dns-operations] Cname errors? In-Reply-To: <20150930150227.GB86614@mx2.yitter.info> References: <5609EC89.70208@lcrcomputer.net> <20150929022325.5F21E38BDFA9@rock.dv.isc.org> <20150929092604.4db7fa6c@casual> <560AB251.7020202@redbarn.org> <20150930143110.5ec6f996@casual> <560BF764.7010706@redbarn.org> <20150930150227.GB86614@mx2.yitter.info> Message-ID: From: Andrew Sullivan > I believe that, if that is the plan for how the Internet is going to > develop in the future, we are doomed. Services on the Internet are > going to be run _decreasingly_ by experts, as nearly as I can tell. True. See most installs of M$ Exchange. > If we are relying on people looking at every knob and every default > setting, we are going to be sorely disappointed. (This is relevant to > all services, including DNS, so I think it's appropriate for this > list.) At the ISC DNS class I took, the instructor described most DNS admins as having learned from the "Tribal Elders". I wish I had had an Elder to learn from. We had a consultant come in and build/configure our first DNS servers and give a few hours of explanation of how to add entries to the one zone. Thanks to Paul Albitz, Cricket Liu and the 2nd edition (and later, the 4th edition) of the Grasshopper Book, I managed not to blow up anything too seriously. After years of going it mostly alone, the class validated a lot of what I had learned and pointed out some better ways to do things. I still would not consider myself an expert. Many years ago, I came up with the title "Guru by Default" - someone who everyone turns to, but only because they know a little bit more about the subject, but not by much. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eromerou at interior.gov.cl Wed Oct 14 16:03:47 2015 From: eromerou at interior.gov.cl (Eduardo Romero Urra) Date: Wed, 14 Oct 2015 13:03:47 -0300 (CLT) Subject: [dns-operations] Question about logger querys with registers points to 127.0.0.1 In-Reply-To: <560D844A.6060005@dns-oarc.net> Message-ID: <164067467.1144191.1444838627323.JavaMail.root@zimbra-cl1.intranet.gov.cl> Hi, I've a logging the named querys on one of public resolver server (ISP) , but after researching we detect some querys that are logged as generated seems itlsef as '127.0.0.1' address, in some of cases the query points to a hostname that resolves also as '127.0.0.1', for example: 28-Sep-2015 09:09:21.528 client 127.0.0.1#28082: query: f5-hk01.gtm.lenovo.com IN A -E N on-authoritative answer: Name: f5-hk01.gtm.lenovo.com Address: 127.0.0.1 Not always the querys points to resolv host with result '127.0.0.1' , but the strange is the origen marked as localhost came from, and always logs using "EDNS mechanism" ( -E ), previously came from a regular query, for example 05-Sep-2015 01:32:20.756 client some-ip-public-client.(1.2.3.4)#53347: query: news.lawsorsing.com IN A + 05-Sep-2015 01:32:20.766 client some-ip-public-client.(1.2.3.4)#34024: query: news.lawsorsing.com IN A + and few seconds later, the "local query" are generated: 05-Sep-2015 01:32:21.160 client 127.0.0.1#25468: query: news.lawsorsing.com IN A -E 05-Sep-2015 01:32:21.161 client 127.0.0.1#2345: query: news.lawsorsing.com IN A -E Someone could explain this please, because the last lines "alone" could made a false positive that the server maybe compromise because are generating query itself. I've suppose that EDNS mechanism could be the cause. The situation is very common with '*.gtm.lenovo.com' GTM sites . Regards Eduardo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edmonds at mycre.ws Wed Oct 14 20:43:04 2015 From: edmonds at mycre.ws (Robert Edmonds) Date: Wed, 14 Oct 2015 16:43:04 -0400 Subject: [dns-operations] Question about logger querys with registers points to 127.0.0.1 In-Reply-To: <164067467.1144191.1444838627323.JavaMail.root@zimbra-cl1.intranet.gov.cl> References: <560D844A.6060005@dns-oarc.net> <164067467.1144191.1444838627323.JavaMail.root@zimbra-cl1.intranet.gov.cl> Message-ID: <20151014204304.GA25554@mycre.ws> "f5-hk01.gtm.lenovo.com" is one of the nameservers for the gtm.lenovo.com zone. "-" in the named query log indicates a non-recursive query (RD bit cleared), and "E" indicates a query that uses EDNS. That sounds like the kind of query that would be sent by a (modern) recursive DNS server looking up a name under the gtm.lenovo.com zone rather than a query sent by a tool like nslookup, but it's interesting that such a query was sent to your nameserver (and by something running on the machine itself), rather than being sent to the Lenovo nameservers. It sounds like you have something that initiates DNS queries that is not the nameserver itself running on the same machine as the nameserver. You might try checking to see if there are any processes that might be the culprit using tools like ps, netstat, lsof, etc., or possibly you might have some exotic firewall rules installed that cause your nameserver to receive DNS queries from source address 127.0.0.1. Eduardo Romero Urra wrote: > Hi, > > I've a logging the named querys on one of public resolver server (ISP) , but after researching we detect some querys that are logged as generated seems itlsef as '127.0.0.1' address, in some of cases the query points to a hostname that resolves also as '127.0.0.1', for example: > > > 28-Sep-2015 09:09:21.528 client 127.0.0.1#28082: query: f5-hk01.gtm.lenovo.com IN A -E > > N on-authoritative answer: > Name: f5-hk01.gtm.lenovo.com > Address: 127.0.0.1 > > Not always the querys points to resolv host with result '127.0.0.1' , but the strange is the origen marked as localhost came from, and always logs using "EDNS mechanism" ( -E ), previously came from a regular query, for example > > > 05-Sep-2015 01:32:20.756 client some-ip-public-client.(1.2.3.4)#53347: query: news.lawsorsing.com IN A + > 05-Sep-2015 01:32:20.766 client some-ip-public-client.(1.2.3.4)#34024: query: news.lawsorsing.com IN A + > > and few seconds later, the "local query" are generated: > > 05-Sep-2015 01:32:21.160 client 127.0.0.1#25468: query: news.lawsorsing.com IN A -E > 05-Sep-2015 01:32:21.161 client 127.0.0.1#2345: query: news.lawsorsing.com IN A -E > > Someone could explain this please, because the last lines "alone" could made a false positive that the server maybe compromise because are generating query itself. I've suppose that EDNS mechanism could be the cause. > > The situation is very common with '*.gtm.lenovo.com' GTM sites . > > > Regards > Eduardo. -- Robert Edmonds From marka at isc.org Thu Oct 15 13:43:14 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 16 Oct 2015 00:43:14 +1100 Subject: [dns-operations] Question about logger querys with registers points to 127.0.0.1 In-Reply-To: Your message of "Wed, 14 Oct 2015 16:43:04 -0400." <20151014204304.GA25554@mycre.ws> References: <560D844A.6060005@dns-oarc.net> <164067467.1144191.1444838627323.JavaMail.root@zimbra-cl1.intranet.gov.cl> <20151014204304.GA25554@mycre.ws> Message-ID: <20151015134315.03E173A899AA@rock.dv.isc.org> Yet another misconfigured load balancer. Lenovo fix your nameservers. The listed nameservers either return NXDOMAIN, SERVFAIL or garbage for their names. See below for full trace. e.g. ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk01.gtm.lenovo.com. @124.127.169.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12190 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk01.gtm.lenovo.com. IN A ;; ANSWER SECTION: f5-hk01.gtm.lenovo.com. 0 IN A 127.0.0.1 ;; AUTHORITY SECTION: lenovo.com. 0 IN NS f5-hk01.gtm.lenovo.com. ;; Query time: 191 msec ;; SERVER: 124.127.169.100#53(124.127.169.100) ;; WHEN: Fri Oct 16 00:31:35 EST 2015 ;; MSG SIZE rcvd: 81 Mark In message <20151014204304.GA25554 at mycre.ws>, Robert Edmonds writes: > "f5-hk01.gtm.lenovo.com" is one of the nameservers for the > gtm.lenovo.com zone. "-" in the named query log indicates a > non-recursive query (RD bit cleared), and "E" indicates a query that > uses EDNS. That sounds like the kind of query that would be sent by a > (modern) recursive DNS server looking up a name under the gtm.lenovo.com > zone rather than a query sent by a tool like nslookup, but it's > interesting that such a query was sent to your nameserver (and by > something running on the machine itself), rather than being sent to the > Lenovo nameservers. > > It sounds like you have something that initiates DNS queries that is not > the nameserver itself running on the same machine as the nameserver. > You might try checking to see if there are any processes that might be > the culprit using tools like ps, netstat, lsof, etc., or possibly you > might have some exotic firewall rules installed that cause your > nameserver to receive DNS queries from source address 127.0.0.1. > > Eduardo Romero Urra wrote: > > Hi, > > > > I've a logging the named querys on one of public resolver server (ISP) , bu > t after researching we detect some querys that are logged as generated seems > itlsef as '127.0.0.1' address, in some of cases the query points to a hostnam > e that resolves also as '127.0.0.1', for example: > > > > > > 28-Sep-2015 09:09:21.528 client 127.0.0.1#28082: query: f5-hk01.gtm.lenovo. > com IN A -E > > > > N on-authoritative answer: > > Name: f5-hk01.gtm.lenovo.com > > Address: 127.0.0.1 > > > > Not always the querys points to resolv host with result '127.0.0.1' , but t > he strange is the origen marked as localhost came from, and always logs using > "EDNS mechanism" ( -E ), previously came from a regular query, for example > > > > > > 05-Sep-2015 01:32:20.756 client some-ip-public-client.(1.2.3.4)#53347: quer > y: news.lawsorsing.com IN A + > > 05-Sep-2015 01:32:20.766 client some-ip-public-client.(1.2.3.4)#34024: quer > y: news.lawsorsing.com IN A + > > > > and few seconds later, the "local query" are generated: > > > > 05-Sep-2015 01:32:21.160 client 127.0.0.1#25468: query: news.lawsorsing.com > IN A -E > > 05-Sep-2015 01:32:21.161 client 127.0.0.1#2345: query: news.lawsorsing.com > IN A -E > > > > Someone could explain this please, because the last lines "alone" could mad > e a false positive that the server maybe compromise because are generating qu > ery itself. I've suppose that EDNS mechanism could be the cause. > > > > The situation is very common with '*.gtm.lenovo.com' GTM sites . > > > > > > Regards > > Eduardo. > > -- > Robert Edmonds > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us01.gtm.lenovo.com. @124.127.169.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28716 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 179 msec ;; SERVER: 124.127.169.100#53(124.127.169.100) ;; WHEN: Fri Oct 16 00:34:08 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us01.gtm.lenovo.com. @114.247.140.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57589 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 399 msec ;; SERVER: 114.247.140.100#53(114.247.140.100) ;; WHEN: Fri Oct 16 00:34:08 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us01.gtm.lenovo.com. @124.127.169.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 23912 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 197 msec ;; SERVER: 124.127.169.101#53(124.127.169.101) ;; WHEN: Fri Oct 16 00:34:08 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us01.gtm.lenovo.com. @114.247.140.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61554 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 384 msec ;; SERVER: 114.247.140.101#53(114.247.140.101) ;; WHEN: Fri Oct 16 00:34:09 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us01.gtm.lenovo.com. @103.30.234.160 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16411 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 127 msec ;; SERVER: 103.30.234.160#53(103.30.234.160) ;; WHEN: Fri Oct 16 00:34:09 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us01.gtm.lenovo.com. @103.30.234.130 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 55657 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us01.gtm.lenovo.com. IN A ;; Query time: 125 msec ;; SERVER: 103.30.234.130#53(103.30.234.130) ;; WHEN: Fri Oct 16 00:34:09 EST 2015 ;; MSG SIZE rcvd: 51 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us01.gtm.lenovo.com. @103.30.232.120 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5220 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 312 msec ;; SERVER: 103.30.232.120#53(103.30.232.120) ;; WHEN: Fri Oct 16 00:34:09 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us01.gtm.lenovo.com. @103.30.232.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49128 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 254 msec ;; SERVER: 103.30.232.121#53(103.30.232.121) ;; WHEN: Fri Oct 16 00:34:09 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us02.gtm.lenovo.com. @124.127.169.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19479 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 186 msec ;; SERVER: 124.127.169.100#53(124.127.169.100) ;; WHEN: Fri Oct 16 00:34:10 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us02.gtm.lenovo.com. @114.247.140.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14593 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 284 msec ;; SERVER: 114.247.140.100#53(114.247.140.100) ;; WHEN: Fri Oct 16 00:34:10 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us02.gtm.lenovo.com. @124.127.169.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 17470 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 189 msec ;; SERVER: 124.127.169.101#53(124.127.169.101) ;; WHEN: Fri Oct 16 00:34:10 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us02.gtm.lenovo.com. @114.247.140.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11553 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 435 msec ;; SERVER: 114.247.140.101#53(114.247.140.101) ;; WHEN: Fri Oct 16 00:34:11 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us02.gtm.lenovo.com. @103.30.234.160 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53994 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 125 msec ;; SERVER: 103.30.234.160#53(103.30.234.160) ;; WHEN: Fri Oct 16 00:34:11 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us02.gtm.lenovo.com. @103.30.234.130 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 20860 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us02.gtm.lenovo.com. IN A ;; Query time: 125 msec ;; SERVER: 103.30.234.130#53(103.30.234.130) ;; WHEN: Fri Oct 16 00:34:11 EST 2015 ;; MSG SIZE rcvd: 51 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us02.gtm.lenovo.com. @103.30.232.120 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14043 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 255 msec ;; SERVER: 103.30.232.120#53(103.30.232.120) ;; WHEN: Fri Oct 16 00:34:11 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-us02.gtm.lenovo.com. @103.30.232.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 47168 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-us02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 254 msec ;; SERVER: 103.30.232.121#53(103.30.232.121) ;; WHEN: Fri Oct 16 00:34:11 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj02.gtm.lenovo.com. @124.127.169.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2132 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 182 msec ;; SERVER: 124.127.169.100#53(124.127.169.100) ;; WHEN: Fri Oct 16 00:34:12 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj02.gtm.lenovo.com. @114.247.140.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 45349 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 392 msec ;; SERVER: 114.247.140.100#53(114.247.140.100) ;; WHEN: Fri Oct 16 00:34:12 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj02.gtm.lenovo.com. @124.127.169.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43082 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 392 msec ;; SERVER: 124.127.169.101#53(124.127.169.101) ;; WHEN: Fri Oct 16 00:34:12 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj02.gtm.lenovo.com. @114.247.140.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57066 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 393 msec ;; SERVER: 114.247.140.101#53(114.247.140.101) ;; WHEN: Fri Oct 16 00:34:13 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj02.gtm.lenovo.com. @103.30.234.160 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27682 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 124 msec ;; SERVER: 103.30.234.160#53(103.30.234.160) ;; WHEN: Fri Oct 16 00:34:13 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj02.gtm.lenovo.com. @103.30.234.130 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56348 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj02.gtm.lenovo.com. IN A ;; Query time: 123 msec ;; SERVER: 103.30.234.130#53(103.30.234.130) ;; WHEN: Fri Oct 16 00:34:13 EST 2015 ;; MSG SIZE rcvd: 51 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj02.gtm.lenovo.com. @103.30.232.120 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34331 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 256 msec ;; SERVER: 103.30.232.120#53(103.30.232.120) ;; WHEN: Fri Oct 16 00:34:13 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj02.gtm.lenovo.com. @103.30.232.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 61510 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 454 msec ;; SERVER: 103.30.232.121#53(103.30.232.121) ;; WHEN: Fri Oct 16 00:34:14 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj01.gtm.lenovo.com. @124.127.169.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42495 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 190 msec ;; SERVER: 124.127.169.100#53(124.127.169.100) ;; WHEN: Fri Oct 16 00:34:14 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj01.gtm.lenovo.com. @114.247.140.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 52704 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 390 msec ;; SERVER: 114.247.140.100#53(114.247.140.100) ;; WHEN: Fri Oct 16 00:34:15 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj01.gtm.lenovo.com. @124.127.169.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 50312 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 385 msec ;; SERVER: 124.127.169.101#53(124.127.169.101) ;; WHEN: Fri Oct 16 00:34:15 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj01.gtm.lenovo.com. @114.247.140.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28824 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 270 msec ;; SERVER: 114.247.140.101#53(114.247.140.101) ;; WHEN: Fri Oct 16 00:34:15 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj01.gtm.lenovo.com. @103.30.234.160 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 58763 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 127 msec ;; SERVER: 103.30.234.160#53(103.30.234.160) ;; WHEN: Fri Oct 16 00:34:15 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj01.gtm.lenovo.com. @103.30.234.130 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47098 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj01.gtm.lenovo.com. IN A ;; Query time: 131 msec ;; SERVER: 103.30.234.130#53(103.30.234.130) ;; WHEN: Fri Oct 16 00:34:16 EST 2015 ;; MSG SIZE rcvd: 51 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj01.gtm.lenovo.com. @103.30.232.120 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 60141 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 253 msec ;; SERVER: 103.30.232.120#53(103.30.232.120) ;; WHEN: Fri Oct 16 00:34:16 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-bj01.gtm.lenovo.com. @103.30.232.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 30500 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-bj01.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 256 msec ;; SERVER: 103.30.232.121#53(103.30.232.121) ;; WHEN: Fri Oct 16 00:34:16 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk01.gtm.lenovo.com. @124.127.169.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25396 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk01.gtm.lenovo.com. IN A ;; ANSWER SECTION: f5-hk01.gtm.lenovo.com. 0 IN A 127.0.0.1 ;; AUTHORITY SECTION: lenovo.com. 0 IN NS f5-hk01.gtm.lenovo.com. ;; Query time: 186 msec ;; SERVER: 124.127.169.100#53(124.127.169.100) ;; WHEN: Fri Oct 16 00:34:16 EST 2015 ;; MSG SIZE rcvd: 81 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk01.gtm.lenovo.com. @114.247.140.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54300 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk01.gtm.lenovo.com. IN A ;; ANSWER SECTION: f5-hk01.gtm.lenovo.com. 0 IN A 127.0.0.1 ;; AUTHORITY SECTION: lenovo.com. 0 IN NS f5-hk01.gtm.lenovo.com. ;; Query time: 280 msec ;; SERVER: 114.247.140.100#53(114.247.140.100) ;; WHEN: Fri Oct 16 00:34:17 EST 2015 ;; MSG SIZE rcvd: 81 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk01.gtm.lenovo.com. @124.127.169.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50981 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk01.gtm.lenovo.com. IN A ;; ANSWER SECTION: f5-hk01.gtm.lenovo.com. 0 IN A 127.0.0.1 ;; AUTHORITY SECTION: lenovo.com. 0 IN NS f5-hk01.gtm.lenovo.com. ;; Query time: 194 msec ;; SERVER: 124.127.169.101#53(124.127.169.101) ;; WHEN: Fri Oct 16 00:34:17 EST 2015 ;; MSG SIZE rcvd: 81 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk01.gtm.lenovo.com. @114.247.140.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37694 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk01.gtm.lenovo.com. IN A ;; ANSWER SECTION: f5-hk01.gtm.lenovo.com. 0 IN A 127.0.0.1 ;; AUTHORITY SECTION: lenovo.com. 0 IN NS f5-hk01.gtm.lenovo.com. ;; Query time: 283 msec ;; SERVER: 114.247.140.101#53(114.247.140.101) ;; WHEN: Fri Oct 16 00:34:17 EST 2015 ;; MSG SIZE rcvd: 81 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk01.gtm.lenovo.com. @103.30.234.160 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51123 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk01.gtm.lenovo.com. IN A ;; ANSWER SECTION: f5-hk01.gtm.lenovo.com. 0 IN A 127.0.0.1 ;; AUTHORITY SECTION: lenovo.com. 0 IN NS f5-hk01.gtm.lenovo.com. ;; Query time: 126 msec ;; SERVER: 103.30.234.160#53(103.30.234.160) ;; WHEN: Fri Oct 16 00:34:17 EST 2015 ;; MSG SIZE rcvd: 81 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk01.gtm.lenovo.com. @103.30.234.130 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28255 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk01.gtm.lenovo.com. IN A ;; Query time: 127 msec ;; SERVER: 103.30.234.130#53(103.30.234.130) ;; WHEN: Fri Oct 16 00:34:17 EST 2015 ;; MSG SIZE rcvd: 51 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk01.gtm.lenovo.com. @103.30.232.120 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31757 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk01.gtm.lenovo.com. IN A ;; ANSWER SECTION: f5-hk01.gtm.lenovo.com. 0 IN A 127.0.0.1 ;; AUTHORITY SECTION: lenovo.com. 0 IN NS f5-hk01.gtm.lenovo.com. ;; Query time: 319 msec ;; SERVER: 103.30.232.120#53(103.30.232.120) ;; WHEN: Fri Oct 16 00:34:18 EST 2015 ;; MSG SIZE rcvd: 81 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk01.gtm.lenovo.com. @103.30.232.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32555 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk01.gtm.lenovo.com. IN A ;; ANSWER SECTION: f5-hk01.gtm.lenovo.com. 0 IN A 127.0.0.1 ;; AUTHORITY SECTION: lenovo.com. 0 IN NS f5-hk01.gtm.lenovo.com. ;; Query time: 252 msec ;; SERVER: 103.30.232.121#53(103.30.232.121) ;; WHEN: Fri Oct 16 00:34:18 EST 2015 ;; MSG SIZE rcvd: 81 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk02.gtm.lenovo.com. @124.127.169.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35319 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 193 msec ;; SERVER: 124.127.169.100#53(124.127.169.100) ;; WHEN: Fri Oct 16 00:34:18 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk02.gtm.lenovo.com. @114.247.140.100 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64430 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 724 10800 3600 604800 60 ;; Query time: 275 msec ;; SERVER: 114.247.140.100#53(114.247.140.100) ;; WHEN: Fri Oct 16 00:34:18 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk02.gtm.lenovo.com. @124.127.169.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9662 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 188 msec ;; SERVER: 124.127.169.101#53(124.127.169.101) ;; WHEN: Fri Oct 16 00:34:19 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk02.gtm.lenovo.com. @114.247.140.101 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36160 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 263 msec ;; SERVER: 114.247.140.101#53(114.247.140.101) ;; WHEN: Fri Oct 16 00:34:19 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk02.gtm.lenovo.com. @103.30.234.160 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40196 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 714 10800 3600 604800 60 ;; Query time: 125 msec ;; SERVER: 103.30.234.160#53(103.30.234.160) ;; WHEN: Fri Oct 16 00:34:19 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk02.gtm.lenovo.com. @103.30.234.130 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 47250 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk02.gtm.lenovo.com. IN A ;; Query time: 128 msec ;; SERVER: 103.30.234.130#53(103.30.234.130) ;; WHEN: Fri Oct 16 00:34:19 EST 2015 ;; MSG SIZE rcvd: 51 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk02.gtm.lenovo.com. @103.30.232.120 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 65289 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 258 msec ;; SERVER: 103.30.232.120#53(103.30.232.120) ;; WHEN: Fri Oct 16 00:34:19 EST 2015 ;; MSG SIZE rcvd: 106 ; <<>> DiG 9.11.0pre-alpha <<>> +norec f5-hk02.gtm.lenovo.com. @103.30.232.121 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 64541 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;f5-hk02.gtm.lenovo.com. IN A ;; AUTHORITY SECTION: lenovo.com. 60 IN SOA f5-hk01.gtm.lenovo.com. hostmaster.f5-hk01.gtm.lenovo.com. 710 10800 3600 604800 60 ;; Query time: 274 msec ;; SERVER: 103.30.232.121#53(103.30.232.121) ;; WHEN: Fri Oct 16 00:34:20 EST 2015 ;; MSG SIZE rcvd: 106 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From tale at akamai.com Thu Oct 15 16:34:29 2015 From: tale at akamai.com (David C Lawrence) Date: Thu, 15 Oct 2015 12:34:29 -0400 Subject: [dns-operations] Question about logger querys with registers points to 127.0.0.1 In-Reply-To: <164067467.1144191.1444838627323.JavaMail.root@zimbra-cl1.intranet.gov.cl> References: <560D844A.6060005@dns-oarc.net> <164067467.1144191.1444838627323.JavaMail.root@zimbra-cl1.intranet.gov.cl> Message-ID: <22047.54677.342397.675336@tale.kendall.corp.akamai.com> Eduardo Romero Urra writes: > Not always the querys points to resolv host with result '127.0.0.1' , but > the strange is the origen marked as localhost came from, and always logs > using "EDNS mechanism" ( -E ), previously came from a regular query, for > example I'm sure the EDNS part is a red herring, and what I suspect is happening is that specifically an NS record for the domain is being pointed to a name that resolves as 127.1. Like, in the case of that f5-hk01.gtm.lenovo.com name, it occasionally shows up as the target of an NS, with the 127.1 address in the additionals section. So the resolver dutifully tries to talk to it in pursuit of whatever name it was trying to figure out. Now the thing about localhost is that since it is internally co-ordinated by your machine, the outgoing request that the nameserver sends is not from its normal external request, but instead it is source from 127.1 to go to 127.1. That's why it shows up in the log that way. From edmonds at mycre.ws Thu Oct 15 17:39:53 2015 From: edmonds at mycre.ws (Robert Edmonds) Date: Thu, 15 Oct 2015 13:39:53 -0400 Subject: [dns-operations] Question about logger querys with registers points to 127.0.0.1 In-Reply-To: <20151015134315.03E173A899AA@rock.dv.isc.org> References: <560D844A.6060005@dns-oarc.net> <164067467.1144191.1444838627323.JavaMail.root@zimbra-cl1.intranet.gov.cl> <20151014204304.GA25554@mycre.ws> <20151015134315.03E173A899AA@rock.dv.isc.org> Message-ID: <20151015173953.GA12243@mycre.ws> Mark Andrews wrote: > Yet another misconfigured load balancer. > > Lenovo fix your nameservers. The listed nameservers either return > NXDOMAIN, SERVFAIL or garbage for their names. See below for full > trace. > ;; ANSWER SECTION: > f5-hk01.gtm.lenovo.com. 0 IN A 127.0.0.1 Oh, right. It's the nameserver querying itself, then. Same with the other domain in the original poster's email. ;; QUESTION SECTION: ;lawsorsing.com. IN A ;; AUTHORITY SECTION: lawsorsing.com. 172800 IN NS dns1.registerfly.com.deleted.gandi.net. lawsorsing.com. 172800 IN NS dns2.registerfly.com.deleted.gandi.net. lawsorsing.com. 172800 IN NS dns3.registerfly.com.deleted.gandi.net. ;; ADDITIONAL SECTION: dns1.registerfly.com.deleted.gandi.net. 172800 IN A 216.40.47.18 dns2.registerfly.com.deleted.gandi.net. 172800 IN A 64.97.159.10 dns3.registerfly.com.deleted.gandi.net. 172800 IN A 65.22.7.10 ;; Query time: 38 msec ;; SERVER: 2001:503:a83e::2:30#53(2001:503:a83e::2:30) ;; WHEN: Thu Oct 15 13:19:25 EDT 2015 ;; MSG SIZE rcvd: 181 The glue records point to addresses that are real but lame nameservers, and actually resolving those nameserver names returns 127.0.0.1 at the gandi.net nameservers. ;; QUESTION SECTION: ;*.deleted.gandi.net. IN A ;; ANSWER SECTION: *.deleted.gandi.net. 86400 IN A 127.0.0.1 Unbound has a "do-not-query-localhost" config option (default enabled) that will prevent sending queries to localhost, but I'm not sure if similar functionality is available in BIND. -- Robert Edmonds From dot at dotat.at Fri Oct 16 09:48:01 2015 From: dot at dotat.at (Tony Finch) Date: Fri, 16 Oct 2015 10:48:01 +0100 Subject: [dns-operations] Question about logger querys with registers points to 127.0.0.1 In-Reply-To: <20151015173953.GA12243@mycre.ws> References: <560D844A.6060005@dns-oarc.net> <164067467.1144191.1444838627323.JavaMail.root@zimbra-cl1.intranet.gov.cl> <20151014204304.GA25554@mycre.ws> <20151015134315.03E173A899AA@rock.dv.isc.org> <20151015173953.GA12243@mycre.ws> Message-ID: Robert Edmonds wrote: > > Unbound has a "do-not-query-localhost" config option (default enabled) > that will prevent sending queries to localhost, but I'm not sure if > similar functionality is available in BIND. Use a server{} clause to declare addresses "bogus". My config has... # Never send queries into bogus address space. # Marks note if BIND has builtin empty zones server 0.0.0.0/8 { bogus yes; }; # server 10.0.0.0/8 { bogus yes; }; # server 100.64.0.0/10 { bogus yes; }; # server 127.0.0.0/8 { bogus yes; }; # server 169.254.0.0/16 { bogus yes; }; # server 172.16.0.0/12 { bogus yes; }; # server 192.0.0.0/24 { bogus yes; }; server 192.0.2.0/24 { bogus yes; }; # server 192.88.99.0/24 { bogus yes; }; server 192.168.0.0/16 { bogus yes; }; # server 198.18.0.0/15 { bogus yes; }; server 198.51.100.0/24 { bogus yes; }; # server 203.0.113.0/24 { bogus yes; }; # server 224.0.0.0/3 { bogus yes; }; server 0000::/3 { bogus yes; }; server 2001:0000::/32 { bogus yes; }; server 2001:0002::/48 { bogus yes; }; server 2001:0010::/28 { bogus yes; }; server 2001:0db8::/32 { bogus yes; }; server 2002::/16 { bogus yes; }; server 3000::/4 { bogus yes; }; server 4000::/2 { bogus yes; }; server 8000::/1 { bogus yes; }; Tony. -- f.anthony.n.finch http://dotat.at/ Sole: Easterly 4 or 5, occasionally 6 in west. Moderate, occasionally rough in west. Showers. Good. From frnkblk at iname.com Sat Oct 17 03:07:34 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Fri, 16 Oct 2015 22:07:34 -0500 Subject: [dns-operations] www.dnssec-or-not.net Message-ID: <000001d10888$f9359d70$eba0d850$@iname.com> On Thursday I reached out to Duane about www.dnssec-or-not.net not consistently returning the AD bit for one our DNS servers. Looking back our DNS server logs I saw some issues starting on the 15th with the name servers for that zone (ns[01].dnssec-or-not.org). Just this evening, starting at 9:57 pm (U.S. Central) I see the zone is not responding at all. Does anyone know if Verisign is deprecating this domain/zone? Frank Oct 15 01:47:56 199.120.69.23 named[20088]: connection refused resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 01:47:56 199.120.69.23 named[20088]: connection refused resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 01:47:56 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:47:56 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:47:56 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:47:56 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:47:56 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:47:56 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:47:57 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:47:57 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:47:57 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:47:57 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:47:58 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:47:58 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:47:59 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:47:59 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:47:59 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:48:00 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:48:00 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:48:00 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:52:56 10.20.0.200 named[6022]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:52:57 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:52:57 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:52:58 10.20.0.200 named[6022]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:52:58 10.20.0.200 named[6022]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:52:59 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:52:59 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:52:59 10.20.0.200 named[6022]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:52:59 10.20.0.200 named[6022]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:53:01 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:53:01 10.20.0.200 named[6022]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:58:56 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:58:57 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:58:57 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:58:58 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:58:58 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:58:59 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:58:59 199.120.69.23 named[20088]: connection refused resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 01:59:00 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 01:59:00 199.120.69.23 named[20088]: connection refused resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:02:56 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:02:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:02:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:02:59 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:02:59 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:02:59 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:02:59 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:03:02 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:03:02 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:03:02 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:03:02 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:03:56 10.20.0.20 named[26126]: error (connection refused) resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 02:03:56 10.20.0.20 named[26126]: error (connection refused) resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:09:57 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:09:58 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:09:58 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:10:04 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:10:04 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:10:04 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:10:04 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:10:04 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:10:05 10.20.0.20 named[26126]: error (connection refused) resolving 'ns1.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:10:05 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.80#53 Oct 15 02:10:05 10.20.0.20 named[26126]: error (connection refused) resolving 'ns0.dnssec-or-not.org/AAAA/IN': 72.13.58.76#53 Oct 15 02:46:56 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 02:46:56 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 02:46:56 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 02:46:56 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 02:46:56 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 03:12:56 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 03:12:56 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 03:12:56 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 03:12:56 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 03:12:56 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 03:43:57 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 03:43:57 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 03:43:58 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 03:43:58 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 03:43:58 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 03:49:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 03:49:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 03:49:57 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 03:49:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 03:49:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 04:25:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 04:25:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 04:25:57 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 04:25:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 04:25:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 04:56:58 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 04:56:58 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 04:56:58 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 04:56:58 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 04:56:58 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 04:57:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 04:57:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 04:57:57 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 04:57:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 04:57:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 05:03:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:03:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 05:04:58 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:04:58 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 05:15:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 05:15:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 05:15:57 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 05:15:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:15:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 05:21:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:21:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 05:22:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:22:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 05:23:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:23:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 05:24:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:24:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 05:30:00 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 05:30:00 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 05:30:00 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 05:30:00 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 05:30:00 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 05:49:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 05:49:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 05:49:57 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 05:49:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:49:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 05:55:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:55:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 05:56:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 05:56:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 06:07:58 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 06:07:58 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 06:07:58 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 06:07:58 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 06:07:58 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 06:08:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 06:08:58 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 06:08:58 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 06:08:58 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 06:08:58 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 06:09:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 06:09:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 06:35:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 06:35:57 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 06:35:57 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 06:35:57 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 06:35:57 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 07:18:58 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 07:18:58 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 07:18:58 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 07:18:58 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 07:18:58 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 07:19:55 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 07:19:55 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 07:19:55 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 07:19:55 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 07:19:55 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 07:25:55 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 07:25:55 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 07:42:33 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 07:42:33 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 07:42:33 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 07:42:33 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 07:42:33 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 08:43:33 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 08:43:33 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 08:43:33 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 08:43:33 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 08:43:33 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 08:49:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 08:49:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 08:49:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 08:49:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 08:49:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 09:50:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 09:50:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 09:50:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 09:50:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 09:50:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 10:06:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 10:06:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 10:06:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 10:06:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 10:06:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 10:12:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 10:12:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 10:48:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 10:48:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 10:48:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 10:48:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 10:48:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 10:54:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 10:54:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 10:54:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 10:54:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 10:54:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 10:55:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 10:55:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 11:11:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 11:11:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 11:11:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 11:11:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 11:11:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 11:32:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 11:32:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 11:32:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 11:32:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 11:32:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 11:33:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 11:33:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 11:33:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 11:33:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 11:33:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 11:39:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 11:39:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 12:00:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 12:00:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 12:00:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 12:00:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 12:00:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 12:16:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 12:16:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 12:16:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 12:16:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 12:16:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 12:52:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 12:52:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 12:52:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 12:52:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 12:52:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 12:53:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 12:53:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 12:53:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 12:53:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 12:53:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 13:19:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 13:19:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 13:19:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 13:19:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 13:19:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 13:20:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 13:20:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 13:36:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 13:36:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 13:36:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 13:36:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 13:36:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 13:37:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 13:37:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 13:37:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 13:37:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 13:37:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 13:38:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 13:38:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 13:39:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 13:39:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 13:49:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 13:49:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 13:49:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 13:49:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 13:49:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 13:50:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 13:50:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 14:01:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 14:01:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 14:01:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 14:01:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 14:01:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 14:12:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 14:12:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 14:12:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 14:12:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 14:12:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 14:13:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 14:13:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 14:13:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 14:13:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 14:13:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 14:19:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 14:19:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 14:40:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 14:40:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 14:40:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 14:40:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 14:40:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 15:16:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 15:16:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 15:16:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 15:16:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 15:16:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 15:27:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 15:27:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 15:27:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 15:27:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 15:27:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 15:58:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 15:58:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 15:58:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 15:58:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 15:58:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 15:59:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 15:59:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 15:59:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 15:59:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 15:59:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 17:20:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 17:20:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 17:20:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 17:20:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 17:20:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 17:26:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 17:26:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 17:26:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 17:26:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 17:26:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 17:42:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 17:42:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 17:42:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 17:42:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 17:42:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 17:58:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 17:58:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 17:58:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 17:58:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 17:58:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 18:04:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 18:04:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 18:04:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 18:04:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 18:04:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 18:05:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 18:05:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 18:11:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 18:11:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 18:17:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 18:17:34 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 18:17:34 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 18:17:34 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 18:17:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 19:23:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 19:23:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 19:23:34 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 19:23:34 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 19:23:34 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 19:54:36 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 19:54:36 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 19:54:36 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 19:54:36 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 19:54:36 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 19:55:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 19:55:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 19:55:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 19:55:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 19:55:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 20:21:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 20:21:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 20:21:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 20:21:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 20:21:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 20:32:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 20:32:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 20:32:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 20:32:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 20:32:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 21:18:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 21:18:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 21:18:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 21:18:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 21:18:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 21:29:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 21:29:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 21:29:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 21:29:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 21:29:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 21:55:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 21:55:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 21:55:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 21:55:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 21:55:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 22:01:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 22:01:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 22:01:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 22:01:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 22:01:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 22:07:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 22:07:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 22:08:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 22:08:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 22:14:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.76#53 Oct 15 22:14:35 199.120.69.23 named[20088]: no valid RRSIG resolving 'www.dnssec-or-not.net/DS/IN': 72.13.58.80#53 Oct 15 22:14:35 199.120.69.23 named[20088]: no valid DS resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.76#53 Oct 15 22:14:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 22:14:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 22:20:35 199.120.69.23 named[20088]: validating www.dnssec-or-not.net/A: bad cache hit (www.dnssec-or-not.net/DS) Oct 15 22:20:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 22:31:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 22:31:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 22:31:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 22:31:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 22:31:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 Oct 15 23:07:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 23:07:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.80#53 Oct 15 23:07:35 199.120.69.23 named[20088]: validating dnssec-or-not.net/DNSKEY: got insecure response; parent indicates it should be secure Oct 15 23:07:35 199.120.69.23 named[20088]: insecurity proof failed resolving 'dnssec-or-not.net/DNSKEY/IN': 72.13.58.76#53 Oct 15 23:07:35 199.120.69.23 named[20088]: broken trust chain resolving 'www.dnssec-or-not.net/A/IN': 72.13.58.80#53 From jabley at hopcount.ca Sat Oct 17 10:45:32 2015 From: jabley at hopcount.ca (Joe Abley) Date: Sat, 17 Oct 2015 06:45:32 -0400 Subject: [dns-operations] www.dnssec-or-not.net In-Reply-To: <000001d10888$f9359d70$eba0d850$@iname.com> References: <000001d10888$f9359d70$eba0d850$@iname.com> Message-ID: Hi Frank, On 16 Oct 2015, at 23:07, frnkblk at iname.com wrote: > On Thursday I reached out to Duane about www.dnssec-or-not.net not > consistently returning the AD bit for one our DNS servers. Looking > back our > DNS server logs I saw some issues starting on the 15th with the name > servers > for that zone (ns[01].dnssec-or-not.org). > > Just this evening, starting at 9:57 pm (U.S. Central) I see the zone > is not > responding at all. The COM servers return a referral for DNSSEC-OR-NOT.COM to the following nameservers: ns0.dnssec-or-not.org (72.13.58.76, no IPv6) ns1.dnssec-or-not.org (72.13.58.80, no IPv6) Those nameservers seem to respond as expected for QTYPE={SOA, A, DNSKEY}, QNAME=DNSSEC-OR-NOT.COM and maybe also AAAA (I get an empty answer section with NOERROR, but the lack of v6 there matches the lack of v6 in the NS set, so maybe that's expected). Perhaps interestingly, I get an empty answer/NOERROR response to queries with QTYPE=NS. I have no way of knowing whether that's normal. The nameservers themselves (via VERSION.BIND/CH/TXT) suggest they're of the hand-rolled variety and also written in perl, so a certain degree of madness is surely to be expected. [scallop:~]% dig @72.13.58.76 dnssec-or-not.com ns +norec ; <<>> DiG 9.8.3-P1 <<>> @72.13.58.76 dnssec-or-not.com ns +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17265 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dnssec-or-not.com. IN NS ;; Query time: 44 msec ;; SERVER: 72.13.58.76#53(72.13.58.76) ;; WHEN: Sat Oct 17 06:37:37 2015 ;; MSG SIZE rcvd: 35 [scallop:~]% dig @72.13.58.80 dnssec-or-not.com ns +norec ; <<>> DiG 9.8.3-P1 <<>> @72.13.58.80 dnssec-or-not.com ns +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10087 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dnssec-or-not.com. IN NS ;; Query time: 43 msec ;; SERVER: 72.13.58.80#53(72.13.58.80) ;; WHEN: Sat Oct 17 06:37:43 2015 ;; MSG SIZE rcvd: 35 [scallop:~]% Using a validating resolver, I get the expected redirect from http://dnssec-or-not.com/ [scallop:~]% curl http://dnssec-or-not.com/ 302 Found

Found

The document has moved here.


Apache/2.2.15 (CentOS) Server at dnssec-or-not.com Port 80
[scallop:~]% and when viewed in a browser, test.dnssec-or-not.com (as redirected) I get confirmation that I'm validating using DNS and SEC, very nice. Maybe those nameservers were just feeling a bit unwell last night, but have since succumbed to a revitalising slumber and have emerged, blinking, into the cold pre-dawn with a renewed sense of vigour. Joe From randy at psg.com Sat Oct 17 11:05:20 2015 From: randy at psg.com (Randy Bush) Date: Sat, 17 Oct 2015 13:05:20 +0200 Subject: [dns-operations] www.dnssec-or-not.net In-Reply-To: References: <000001d10888$f9359d70$eba0d850$@iname.com> Message-ID: > ns0.dnssec-or-not.org (72.13.58.76, no IPv6) > ns1.dnssec-or-not.org (72.13.58.80, no IPv6) nice diversity From frnkblk at iname.com Sat Oct 17 11:23:44 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sat, 17 Oct 2015 06:23:44 -0500 Subject: [dns-operations] www.dnssec-or-not.net In-Reply-To: References: <000001d10888$f9359d70$eba0d850$@iname.com> Message-ID: <000901d108ce$4a3afcc0$deb0f640$@iname.com> Yes, the issue resolved by 11:20 pm, but the 10+ DNS servers I tried before then were timing out. See this output from last night: root at nagios:/home/fbulk# dig-all www.dnssec-or-not.net +short +time=1 | more ============================================ DNS server: 10.20.0.10 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @10.20.0.10 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 2607:fe28:0:4000::10 ; <<>> DiG 9.7.3 <<>> -6 www.dnssec-or-not.net +short +time=1 @2607:fe28:0:4000::10 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 10.20.0.20 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @10.20.0.20 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 2607:fe28:0:4000::20 ; <<>> DiG 9.7.3 <<>> -6 www.dnssec-or-not.net +short +time=1 @2607:fe28:0:4000::20 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 10.20.0.100 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @10.20.0.100 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 2607:fe28:0:4000::100 ; <<>> DiG 9.7.3 <<>> -6 www.dnssec-or-not.net +short +time=1 @2607:fe28:0:4000::100 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 10.20.0.200 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @10.20.0.200 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 2607:fe28:0:4000::200 ; <<>> DiG 9.7.3 <<>> -6 www.dnssec-or-not.net +short +time=1 @2607:fe28:0:4000::200 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 96.31.0.32 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @96.31.0.32 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 2607:fe28:0:1000::32 ============================================ DNS server: 10.20.0.5 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @10.20.0.5 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 96.31.0.5 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @96.31.0.5 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 2607:fe28:0:1000::5 ; <<>> DiG 9.7.3 <<>> -6 www.dnssec-or-not.net +short +time=1 @2607:fe28:0:1000::5 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 10.20.0.8 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @10.20.0.8 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 96.31.0.8 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @96.31.0.8 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 2607:fe28:0:1000::8 ; <<>> DiG 9.7.3 <<>> -6 www.dnssec-or-not.net +short +time=1 @2607:fe28:0:1000::8 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 199.120.69.24 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @199.120.69.24 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 167.142.225.5 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @167.142.225.5 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 167.142.225.6 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @167.142.225.6 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 192.168.0.12 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @192.168.0.12 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 192.168.0.93 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @192.168.0.93 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 192.168.0.94 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @192.168.0.94 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 8.8.8.8 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @8.8.8.8 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 8.8.4.4 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @8.8.4.4 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 208.67.222.222 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @208.67.222.222 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ DNS server: 208.67.220.220 ; <<>> DiG 9.7.3 <<>> www.dnssec-or-not.net +short +time=1 @208.67.220.220 ;; global options: +cmd ;; connection timed out; no servers could be reached ============================================ Frank -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Saturday, October 17, 2015 5:46 AM To: frnkblk at iname.com Cc: dns-operations at dns-oarc.net Subject: Re: [dns-operations] www.dnssec-or-not.net Hi Frank, On 16 Oct 2015, at 23:07, frnkblk at iname.com wrote: > On Thursday I reached out to Duane about www.dnssec-or-not.net not > consistently returning the AD bit for one our DNS servers. Looking > back our > DNS server logs I saw some issues starting on the 15th with the name > servers > for that zone (ns[01].dnssec-or-not.org). > > Just this evening, starting at 9:57 pm (U.S. Central) I see the zone > is not > responding at all. The COM servers return a referral for DNSSEC-OR-NOT.COM to the following nameservers: ns0.dnssec-or-not.org (72.13.58.76, no IPv6) ns1.dnssec-or-not.org (72.13.58.80, no IPv6) Those nameservers seem to respond as expected for QTYPE={SOA, A, DNSKEY}, QNAME=DNSSEC-OR-NOT.COM and maybe also AAAA (I get an empty answer section with NOERROR, but the lack of v6 there matches the lack of v6 in the NS set, so maybe that's expected). Perhaps interestingly, I get an empty answer/NOERROR response to queries with QTYPE=NS. I have no way of knowing whether that's normal. The nameservers themselves (via VERSION.BIND/CH/TXT) suggest they're of the hand-rolled variety and also written in perl, so a certain degree of madness is surely to be expected. [scallop:~]% dig @72.13.58.76 dnssec-or-not.com ns +norec ; <<>> DiG 9.8.3-P1 <<>> @72.13.58.76 dnssec-or-not.com ns +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17265 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dnssec-or-not.com. IN NS ;; Query time: 44 msec ;; SERVER: 72.13.58.76#53(72.13.58.76) ;; WHEN: Sat Oct 17 06:37:37 2015 ;; MSG SIZE rcvd: 35 [scallop:~]% dig @72.13.58.80 dnssec-or-not.com ns +norec ; <<>> DiG 9.8.3-P1 <<>> @72.13.58.80 dnssec-or-not.com ns +norec ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10087 ;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dnssec-or-not.com. IN NS ;; Query time: 43 msec ;; SERVER: 72.13.58.80#53(72.13.58.80) ;; WHEN: Sat Oct 17 06:37:43 2015 ;; MSG SIZE rcvd: 35 [scallop:~]% Using a validating resolver, I get the expected redirect from http://dnssec-or-not.com/ [scallop:~]% curl http://dnssec-or-not.com/ 302 Found

Found

The document has moved here.


Apache/2.2.15 (CentOS) Server at dnssec-or-not.com Port 80
[scallop:~]% and when viewed in a browser, test.dnssec-or-not.com (as redirected) I get confirmation that I'm validating using DNS and SEC, very nice. Maybe those nameservers were just feeling a bit unwell last night, but have since succumbed to a revitalising slumber and have emerged, blinking, into the cold pre-dawn with a renewed sense of vigour. Joe From jabley at hopcount.ca Sat Oct 17 12:19:35 2015 From: jabley at hopcount.ca (Joe Abley) Date: Sat, 17 Oct 2015 08:19:35 -0400 Subject: [dns-operations] www.dnssec-or-not.net In-Reply-To: <000901d108ce$4a3afcc0$deb0f640$@iname.com> References: <000001d10888$f9359d70$eba0d850$@iname.com> <000901d108ce$4a3afcc0$deb0f640$@iname.com> Message-ID: <34055E36-C3FF-4003-B6F1-7BF9A405267C@hopcount.ca> On 17 Oct 2015, at 7:23, frnkblk at iname.com wrote: > Yes, the issue resolved by 11:20 pm, but the 10+ DNS servers I tried before > then were timing out. You should probably ask for your money back. From frnkblk at iname.com Sat Oct 17 13:07:51 2015 From: frnkblk at iname.com (frnkblk at iname.com) Date: Sat, 17 Oct 2015 08:07:51 -0500 Subject: [dns-operations] www.dnssec-or-not.net In-Reply-To: <34055E36-C3FF-4003-B6F1-7BF9A405267C@hopcount.ca> References: <000001d10888$f9359d70$eba0d850$@iname.com> <000901d108ce$4a3afcc0$deb0f640$@iname.com> <34055E36-C3FF-4003-B6F1-7BF9A405267C@hopcount.ca> Message-ID: <000a01d108dc$d569e7d0$803db770$@iname.com> Sorry, did not mean to suggest Verisgn owed it to me to keep servers up 24/7, just making the wider community aware on the off-chance someone from Verisign's DNS team is on this list. We use these servers as litmus tests that our own DNS resolver is properly performing DNSsec validation. Frank -----Original Message----- From: Joe Abley [mailto:jabley at hopcount.ca] Sent: Saturday, October 17, 2015 7:20 AM To: frnkblk at iname.com Cc: dns-operations at dns-oarc.net Subject: Re: [dns-operations] www.dnssec-or-not.net On 17 Oct 2015, at 7:23, frnkblk at iname.com wrote: > Yes, the issue resolved by 11:20 pm, but the 10+ DNS servers I tried before > then were timing out. You should probably ask for your money back. From amankin at verisign.com Sat Oct 17 14:04:32 2015 From: amankin at verisign.com (Mankin, Allison) Date: Sat, 17 Oct 2015 14:04:32 +0000 Subject: [dns-operations] http://www.dnssec-or-not.net In-Reply-To: <000a01d108dc$d569e7d0$803db770$@iname.com> References: <000001d10888$f9359d70$eba0d850$@iname.com> <000901d108ce$4a3afcc0$deb0f640$@iname.com> <34055E36-C3FF-4003-B6F1-7BF9A405267C@hopcount.ca>, <000a01d108dc$d569e7d0$803db770$@iname.com> Message-ID: The www.dnssec-or-not service is offline now for a bug fix. We apologize for causing some folks inconvenience on this. Allison Sent from my iPhone > On Oct 17, 2015, at 9:16 AM, "frnkblk at iname.com" wrote: > > Sorry, did not mean to suggest Verisgn owed it to me to keep servers up > 24/7, just making the wider community aware on the off-chance someone from> Verisign's DNS team is on this list. We use these servers as litmus tests> that our own DNS resolver is properly performing DNSsec validation. > > Frank > > -----Original Message----- > From: Joe Abley [mailto:jabley at hopcount.ca] > Sent: Saturday, October 17, 2015 7:20 AM > To: frnkblk at iname.com > Cc: dns-operations at dns-oarc.net > Subject: Re: [dns-operations] http://www.dnssec-or-not.net > >> On 17 Oct 2015, at 7:23, frnkblk at iname.com wrote: >> >> Yes, the issue resolved by 11:20 pm, but the 10+ DNS servers I tried > before >> then were timing out. > > You should probably ask for your money back. > > > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs > From davew at hireahit.com Sun Oct 18 06:56:56 2015 From: davew at hireahit.com (Dave Warren) Date: Sat, 17 Oct 2015 23:56:56 -0700 Subject: [dns-operations] http://www.dnssec-or-not.net In-Reply-To: References: <000001d10888$f9359d70$eba0d850$@iname.com> <000901d108ce$4a3afcc0$deb0f640$@iname.com> <34055E36-C3FF-4003-B6F1-7BF9A405267C@hopcount.ca>, <000a01d108dc$d569e7d0$803db770$@iname.com> Message-ID: <562342B8.5040604@hireahit.com> Thanks for the info, and for running the service, it's useful and appreciated. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren On 2015-10-17 07:04, Mankin, Allison wrote: > The www.dnssec-or-not service is offline now for a bug fix. We apologize for causing some folks inconvenience on this. > > Allison > From bortzmeyer at nic.fr Sun Oct 18 15:33:41 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 18 Oct 2015 17:33:41 +0200 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not Message-ID: <20151018153341.GA11366@sources.org> I had issues with the domain kura.io, since the name servers always reply with TC=0 (on IPv4; their IPv6 behaviour is more common). According to the DNS hoster, Rage4, it is for "dDoS protection" (I assume the goal is to make reflection attacks impossible). It is the first time I meet this behaviour in the wild. Is it a good idea? If not, should testing programs like ZoneMaster flag such behaviour as risky? I can reproduce it with NSD (ipv4-edns-size: 60) but not with other programs. Any idea how to do it with BIND or Knot (BIND has max-udp-size but, apparently, it is capped to 512 bytes even if a lower value is indicated, Knot has max-udp-payload but the server refuses to start if it's too low "EDNS payload size is lower than 1220 bytes for DNSSEC zone") From shane at time-travellers.org Sun Oct 18 16:21:50 2015 From: shane at time-travellers.org (Shane Kerr) Date: Sun, 18 Oct 2015 17:21:50 +0100 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <20151018153341.GA11366@sources.org> References: <20151018153341.GA11366@sources.org> Message-ID: <59F66631-0555-48B0-9FDD-1914CFE8C17B@time-travellers.org> Stephane, At BII we had to change source code on BIND and PowerDNS to test the behavior. (With PowerDNS it was a one line change because there was already an option to truncate all ANY queries.) :) We can send you some patches for testing if you want. Cheers, -- Shane Stephane Bortzmeyer schreef op 18 oktober 2015 16:33:41 GMT+01:00: >I had issues with the domain kura.io, since the name servers always >reply with TC=0 (on IPv4; their IPv6 behaviour is more >common). According to the DNS hoster, Rage4, it is for "dDoS >protection" (I assume the goal is to make reflection attacks >impossible). > >It is the first time I meet this behaviour in the wild. > >Is it a good idea? > >If not, should testing programs like ZoneMaster > flag such behaviour as risky? > >I can reproduce it with NSD (ipv4-edns-size: 60) but not with other >programs. Any idea how to do it with BIND or Knot (BIND has >max-udp-size but, apparently, it is capped to 512 bytes even if a >lower value is indicated, Knot has max-udp-payload but the server >refuses to start if it's too low "EDNS payload size is lower than 1220 >bytes for DNSSEC zone") > >_______________________________________________ >dns-operations mailing list >dns-operations at lists.dns-oarc.net >https://lists.dns-oarc.net/mailman/listinfo/dns-operations >dns-jobs mailing list >https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From muks at isc.org Sun Oct 18 16:32:12 2015 From: muks at isc.org (Mukund Sivaraman) Date: Sun, 18 Oct 2015 22:02:12 +0530 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <20151018153341.GA11366@sources.org> References: <20151018153341.GA11366@sources.org> Message-ID: <20151018163212.GA19994@jurassic.l0.malgudi.org> Hi Stephane On Sun, Oct 18, 2015 at 05:33:41PM +0200, Stephane Bortzmeyer wrote: > I had issues with the domain kura.io, since the name servers always > reply with TC=0 (on IPv4; their IPv6 behaviour is more > common). According to the DNS hoster, Rage4, it is for "dDoS > protection" (I assume the goal is to make reflection attacks > impossible). > > It is the first time I meet this behaviour in the wild. From the subject, you probably mean TC=1. I think Cloudfare tried this for sometime IIRC. > Is it a good idea? No, I don't think so. There is lot of talk these days suggesting directly using TCP for DNS due to all the issues UDP has. A local caching resolver typically spends a lot of its time iterating queries to domains that have medium to high popularity. TCP doubles iteration time vs. UDP due to the connection setup. As DNS is at the head of any network user interaction, it increases the average turnaround time significantly. Resolvers that are not "near" the nameservers of such domains (such as resolvers based in India with high RTT to many parts of the world) are affected enough that this becomes conspicuous to a user. Have you seen "Looking up..." messages in the status bar of a browser? Opinions vary. I think it's a bad idea to skip UDP, and not everybody who's pushing TCP-only is in a place to appreciate it. This also involves UDP proposals that add more roundtrips. There are other concerns about whether network stacks and implementations are ready to handle the onslaught of TCP-only DNS traffic (which involves additional state). That's another topic. Mukund -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From muks at isc.org Sun Oct 18 16:39:05 2015 From: muks at isc.org (Mukund Sivaraman) Date: Sun, 18 Oct 2015 22:09:05 +0530 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <20151018163212.GA19994@jurassic.l0.malgudi.org> References: <20151018153341.GA11366@sources.org> <20151018163212.GA19994@jurassic.l0.malgudi.org> Message-ID: <20151018163905.GA26009@jurassic.l0.malgudi.org> On Sun, Oct 18, 2015 at 10:02:12PM +0530, Mukund Sivaraman wrote: > > Is it a good idea? > > No, I don't think so. There is lot of talk these days suggesting > directly using TCP for DNS due to all the issues UDP has. BTW, note that replying with TC=1 triples RTT over UDP as a resolver today will first try UDP (1 roundtrip), then noticing TC=1, retry with TCP (+2 for first data). Mukund -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From paul at redbarn.org Sun Oct 18 16:39:47 2015 From: paul at redbarn.org (Paul Vixie) Date: Sun, 18 Oct 2015 09:39:47 -0700 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <20151018153341.GA11366@sources.org> References: <20151018153341.GA11366@sources.org> Message-ID: <5588879.MPbWglXCTU@linux-rfx1> On Sunday, October 18, 2015 17:33:41 Stephane Bortzmeyer wrote: > I had issues with the domain kura.io, since the name servers always > reply with TC=0 (on IPv4; their IPv6 behaviour is more > common). ... i think you mean TC=1. this supposed anti-ddos behaviour is, i heard from somewhere, patented. at least, there's a variant where the first UDP query get TC=1 and only after the client demonstrates that they heard your TC=1 and properly followed up with a TCP transaction, is UDP answered normally. that variant is, i think, patented. -- Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From markjr at easydns.com Sun Oct 18 18:22:31 2015 From: markjr at easydns.com (Mark Jeftovic) Date: Sun, 18 Oct 2015 14:22:31 -0400 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <5588879.MPbWglXCTU@linux-rfx1> References: <20151018153341.GA11366@sources.org> <5588879.MPbWglXCTU@linux-rfx1> Message-ID: <5623E367.2010107@easydns.com> On 2015-10-18 12:39 PM, Paul Vixie wrote: > On Sunday, October 18, 2015 17:33:41 Stephane Bortzmeyer wrote: >> I had issues with the domain kura.io, since the name servers >> always reply with TC=0 (on IPv4; their IPv6 behaviour is more >> common). ... > > i think you mean TC=1. > > this supposed anti-ddos behaviour is, i heard from somewhere, > patented. at least, there's a variant where the first UDP query get > TC=1 and only after the client demonstrates that they heard your > TC=1 and properly followed up with a TCP transaction, is UDP > answered normally. that variant is, i think, patented. > I was also going to clarify that he probably means TC=1 Yes this is a common DDoS mitigation technique and it works pretty well for some situations. I'm not surprised to hear somebody patented this, I could almost hazard a guess who (but I won't) I would not do it all the time however, because we've seen cases where some devices / resolvers fail badly on the TCP retry (like they don't do it, won't do it), such as some mobile devices on some wireless networks. It's ok to do this in a hair-on-fire situation IMHO (but I'm of the opinion it's ok to do almost anything in a hair-on-fire situation, such as dropping ANY's on the floor, whatever it takes) - mark -- Mark Jeftovic, Founder & CEO, easyDNS Technologies Inc. Company Website: http://easydns.com Vote For Mark in Canada's Federal Election: http://markjeftovic.ca +1-416-535-8672 ext 225 From bert.hubert at netherlabs.nl Sun Oct 18 18:33:19 2015 From: bert.hubert at netherlabs.nl (bert hubert) Date: Sun, 18 Oct 2015 20:33:19 +0200 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <59F66631-0555-48B0-9FDD-1914CFE8C17B@time-travellers.org> References: <20151018153341.GA11366@sources.org> <59F66631-0555-48B0-9FDD-1914CFE8C17B@time-travellers.org> Message-ID: <20151018183318.GA15600@xs.powerdns.com> On Sun, Oct 18, 2015 at 05:21:50PM +0100, Shane Kerr wrote: > At BII we had to change source code on BIND and PowerDNS to test the > behavior. (With PowerDNS it was a one line change because there was > already an option to truncate all ANY queries.) :) So is this wise, I dont know. We have one relatively largescale resolver operator doing TC=1 for everything via dnsdist, and they report it works for them. I think this is a university campus with DoS issues caused by their residents. You can configure this as follows in dnsdist: addAction({"0.0.0.0/0", "::/0"}, tcAction()) There are other ways of achieving the same effect too. Bert From paul at redbarn.org Sun Oct 18 19:46:59 2015 From: paul at redbarn.org (Paul Vixie) Date: Sun, 18 Oct 2015 12:46:59 -0700 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <5623E367.2010107@easydns.com> References: <20151018153341.GA11366@sources.org> <5588879.MPbWglXCTU@linux-rfx1> <5623E367.2010107@easydns.com> Message-ID: <4027897.BBNOr1A0zE@linux-rfx1> On Sunday, October 18, 2015 14:22:31 Mark Jeftovic wrote: > > Yes this is a common DDoS mitigation technique and it works pretty > well for some situations. I'm not surprised to hear somebody patented > this, I could almost hazard a guess who (but I won't) > > I would not do it all the time however, because we've seen cases where > some devices / resolvers fail badly on the TCP retry (like they don't > do it, won't do it), such as some mobile devices on some wireless > networks. > > It's ok to do this in a hair-on-fire situation IMHO (but I'm of the > opinion it's ok to do almost anything in a hair-on-fire situation, > such as dropping ANY's on the floor, whatever it takes) i am -1 to all forms of modal defense. for that reason, see DNS RRL. -- Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From amankin at verisign.com Sun Oct 18 20:09:27 2015 From: amankin at verisign.com (Mankin, Allison) Date: Sun, 18 Oct 2015 20:09:27 +0000 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <5588879.MPbWglXCTU@linux-rfx1> References: <20151018153341.GA11366@sources.org>, <5588879.MPbWglXCTU@linux-rfx1> Message-ID: <6340F77F-AF0A-4C7B-A391-FB91216E1E31@verisign.com> Hi Paul, i think you mean TC=1. this supposed anti-ddos behaviour is, i heard from somewhere, patented. at least, there's a variant where the first UDP query get TC=1 and only after the client demonstrates that they heard your TC=1 and properly followed up with a TCP transaction, is UDP answered normally. that variant is, i think, patented. This Riverhead patent, maybe? https://patentimages.storage.googleapis.com/pdfs/US6907525.pdf Paul _______________________________________________ dns-operations mailing list dns-operations at lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick.jones2 at hpe.com Sun Oct 18 23:14:37 2015 From: rick.jones2 at hpe.com (Rick Jones) Date: Sun, 18 Oct 2015 16:14:37 -0700 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <20151018163905.GA26009@jurassic.l0.malgudi.org> References: <20151018153341.GA11366@sources.org> <20151018163212.GA19994@jurassic.l0.malgudi.org> <20151018163905.GA26009@jurassic.l0.malgudi.org> Message-ID: <562427DD.9000108@hpe.com> On 10/18/2015 09:39 AM, Mukund Sivaraman wrote: > On Sun, Oct 18, 2015 at 10:02:12PM +0530, Mukund Sivaraman wrote: >>> Is it a good idea? >> >> No, I don't think so. There is lot of talk these days suggesting >> directly using TCP for DNS due to all the issues UDP has. > > BTW, note that replying with TC=1 triples RTT over UDP as a resolver > today will first try UDP (1 roundtrip), then noticing TC=1, retry with > TCP (+2 for first data). Without coming out either in favor or opposed, I will point-out there exists (in Linux at least) TCP FastOpen these days which would allow the TCP-based query to be one RTT - after the first "traditional" exchange including the fast open option. rick jones From dns at fl1ger.de Mon Oct 19 06:28:28 2015 From: dns at fl1ger.de (Ralf Weber) Date: Mon, 19 Oct 2015 08:28:28 +0200 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <20151018183318.GA15600@xs.powerdns.com> References: <20151018153341.GA11366@sources.org> <59F66631-0555-48B0-9FDD-1914CFE8C17B@time-travellers.org> <20151018183318.GA15600@xs.powerdns.com> Message-ID: <6ED0561B-FEF2-4DEC-8281-FB175238910E@fl1ger.de> Moin! On 18 Oct 2015, at 20:33, bert hubert wrote: > On Sun, Oct 18, 2015 at 05:21:50PM +0100, Shane Kerr wrote: >> At BII we had to change source code on BIND and PowerDNS to test the >> behavior. (With PowerDNS it was a one line change because there was >> already an option to truncate all ANY queries.) :) > > So is this wise, I dont know. We have one relatively largescale > resolver > operator doing TC=1 for everything via dnsdist, and they report it > works for > them. Interesting. My experiences with clients switching to TCP have been mixed, but my testing was a couple of years ago with CPEs primarily. Just out of curiosity is the connection from dnsdist to the actual resolver also TCP or is that UDP? In general answering TC=1 for every query seems like a bad idea as it triples the RTT for every query, as other said. On the authoritative side this mitigated by resolvers caching. For this domain I didn't see the truncate all behaviour when I tried to reach it, so maybe it was something they did under attack. On the resolver side I am pretty sure it would slow down things noticeably. > I think this is a university campus with DoS issues caused by their > residents. That might explain why they don't complain (slow service still is better than no service ;-). So long -Ralf From paul at redbarn.org Mon Oct 19 07:06:30 2015 From: paul at redbarn.org (Paul Vixie) Date: Mon, 19 Oct 2015 00:06:30 -0700 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <6ED0561B-FEF2-4DEC-8281-FB175238910E@fl1ger.de> References: <20151018153341.GA11366@sources.org> <20151018183318.GA15600@xs.powerdns.com> <6ED0561B-FEF2-4DEC-8281-FB175238910E@fl1ger.de> Message-ID: <3776892.2k03IlMpZi@linux-rfx1> On Monday, October 19, 2015 08:28:28 Ralf Weber wrote: > Moin! Blargh! > ... > In general answering TC=1 for every query seems like a bad idea as it > triples the RTT for every query, as other said. noone has argued in favour of that. noone i know has done it in production. and the patent i'm thinking of doesn't work that way. so, let's discuss what's actually being done: process_udp(src_ip, src_port, dns_payload) { if (!has_done_tcp_recently(src_ip)) send_tc_1(src_ip, src_port, dns_payload); return; } // answer normally } the function has_done_tcp_recently() can be a time-series bloom filter, thus approximate for non-negative answers, an acceptable loss of performance since it means that on positive collision ("maybe"), an extra TCP session is incurred. it's still a bad idea, even though most UDP queries are answered without TC=1. -- Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From paul at redbarn.org Mon Oct 19 07:06:30 2015 From: paul at redbarn.org (Paul Vixie) Date: Mon, 19 Oct 2015 00:06:30 -0700 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <6ED0561B-FEF2-4DEC-8281-FB175238910E@fl1ger.de> References: <20151018153341.GA11366@sources.org> <20151018183318.GA15600@xs.powerdns.com> <6ED0561B-FEF2-4DEC-8281-FB175238910E@fl1ger.de> Message-ID: <3776892.2k03IlMpZi@linux-rfx1> On Monday, October 19, 2015 08:28:28 Ralf Weber wrote: > Moin! Blargh! > ... > In general answering TC=1 for every query seems like a bad idea as it > triples the RTT for every query, as other said. noone has argued in favour of that. noone i know has done it in production. and the patent i'm thinking of doesn't work that way. so, let's discuss what's actually being done: process_udp(src_ip, src_port, dns_payload) { if (!has_done_tcp_recently(src_ip)) send_tc_1(src_ip, src_port, dns_payload); return; } // answer normally } the function has_done_tcp_recently() can be a time-series bloom filter, thus approximate for non-negative answers, an acceptable loss of performance since it means that on positive collision ("maybe"), an extra TCP session is incurred. it's still a bad idea, even though most UDP queries are answered without TC=1. -- Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From dns at fl1ger.de Mon Oct 19 08:22:39 2015 From: dns at fl1ger.de (Ralf Weber) Date: Mon, 19 Oct 2015 10:22:39 +0200 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <3776892.2k03IlMpZi@linux-rfx1> References: <20151018153341.GA11366@sources.org> <20151018183318.GA15600@xs.powerdns.com> <6ED0561B-FEF2-4DEC-8281-FB175238910E@fl1ger.de> <3776892.2k03IlMpZi@linux-rfx1> Message-ID: <16693E02-65B1-4E80-BC53-020FC8AB1B19@fl1ger.de> Moin! On 19 Oct 2015, at 9:06, Paul Vixie wrote: > On Monday, October 19, 2015 08:28:28 Ralf Weber wrote: >> In general answering TC=1 for every query seems like a bad idea as it >> triples the RTT for every query, as other said. > > noone has argued in favour of that. noone i know has done it in > production. Stephane original mail stated that he has seen this behaviour on IPv4 with the name servers for kura.io and Berts email stated that he knows an resolver operator that does that. So while it may not be someone you know it looks like it is done and IMHO it is a bad idea. > and the patent i'm thinking of doesn't work that way. I haven't talked about that at all and honestly whenever someone talks about patents I don't follow the thread any longer as IANAL and I don't want to spoil my day thinking about it. So long -Ralf From dot at dotat.at Mon Oct 19 11:38:17 2015 From: dot at dotat.at (Tony Finch) Date: Mon, 19 Oct 2015 12:38:17 +0100 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <20151018153341.GA11366@sources.org> References: <20151018153341.GA11366@sources.org> Message-ID: Stephane Bortzmeyer wrote: > > I can reproduce it with NSD (ipv4-edns-size: 60) but not with other > programs. Any idea how to do it with BIND or Knot You should get this effect using RRL with slip=1 Tony. -- f.anthony.n.finch http://dotat.at/ Fitzroy: Northeasterly 5 to 7, increasing gale 8 at times in south. Moderate or rough, becoming very rough in south. Rain or thundery showers in south. Moderate or good, occasionally poor. From paul at redbarn.org Mon Oct 19 17:16:11 2015 From: paul at redbarn.org (Paul Vixie) Date: Mon, 19 Oct 2015 10:16:11 -0700 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: References: <20151018153341.GA11366@sources.org> Message-ID: <2246785.9G8M1MizFP@linux-rfx1> On Monday, October 19, 2015 12:38:17 Tony Finch wrote: > Stephane Bortzmeyer wrote: > > I can reproduce it with NSD (ipv4-edns-size: 60) but not with other > > programs. Any idea how to do it with BIND or Knot > > You should get this effect using RRL with slip=1 for more commentary on slip=1, see: http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/ -- Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From marka at isc.org Mon Oct 19 20:49:34 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 20 Oct 2015 07:49:34 +1100 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: Your message of "Mon, 19 Oct 2015 10:16:11 -0700." <2246785.9G8M1MizFP@linux-rfx1> References: <20151018153341.GA11366@sources.org> <2246785.9G8M1MizFP@linux-rfx1> Message-ID: <20151019204934.972BE3AC4575@rock.dv.isc.org> In message <2246785.9G8M1MizFP at linux-rfx1>, Paul Vixie writes: > On Monday, October 19, 2015 12:38:17 Tony Finch wrote: > > Stephane Bortzmeyer wrote: > > > I can reproduce it with NSD (ipv4-edns-size: 60) but not with other > > > programs. Any idea how to do it with BIND or Knot > > > > You should get this effect using RRL with slip=1 > > for more commentary on slip=1, see: > > http://www.circleid.com/posts/20130913_on_the_time_value_of_security_featu > res_in_dns/ > > -- > Paul With EDNS COOKIES one can require a good server cookie before providing more of a answer than just BADCOOKIE over UDP. This is similar in nature to always sending TC=1 but keeps the traffic on UDP rather than switching the traffic to TCP. It also doesn't require the authoritative server to keep any per client state. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From songlinjian at gmail.com Tue Oct 20 04:11:39 2015 From: songlinjian at gmail.com (Davey Song) Date: Tue, 20 Oct 2015 12:11:39 +0800 Subject: [dns-operations] Finalized Agenda Re: Yeti DNS Workshop 2015-10-31 (Pre-IETF 94) In-Reply-To: <0B0A389D-C688-4012-B465-FC41957BCD5A@gmail.com> References: <147DB8C4-B247-47DD-A92D-AD6CD5819A89@gmail.com> <0B0A389D-C688-4012-B465-FC41957BCD5A@gmail.com> Message-ID: <5F016FEC-717C-4B0C-B60F-83FE0C160C55@gmail.com> Hi colleagues, We finalize the agenda of this workshop ; ) **In order to receive further information like slides, remote access link, please send mail to Davey or coordinators at lists.yeti-dns.org to registry your attendance (or remote participation).** Event: Yeti DNS Project Workshop Time: 13:00-17:00, 31st, Oct, 2015 (a day before IETF meeting) Location: Room 514 in the Pacifico Yokohama Conference Center Host: BII Sponsor: Yeti Coordinators Draft Agenda: * Welcome address (5 min) * Keynote speech: From 2005 to 2015: Eleven Years (and Counting!) of Responsible Alternate Rootism (Paul Vixie) (20 min+10min Q&A) * Yeti project Introduction and status update (30 min+10min Q&A) * Problem Statement/Motivation * System Status (Server, traffic, operation bugs) * Technical findings Coffee break (15 min) (Some research done by Yeti members and invited talk) * Research and Experiments in BII lab (30 min+10min Q&A) * Multi-DM/Multi-ZSK, Root renumbering issue, KsK rollever and DNS Fragments * Monitoring and measuring Yeti root name servers, Stephane Bortzmeyer (20 min+10min Q&A) * Yeti experiment in MSK-IX , Dmitry Kovalenko (20 min+10 min Q&A) * AS112 update , Keith Mitchell (20 min+10 min Q&A)) Cheers, Davey > ? 2015?10?13??16:14?Davey Song > ??? > > An update for the Workshop (Time and Location confirmed!) > > Time: 13:00-17:00 , 31st, October (Saturday, one day before IETF) > Location: Pacifico Yokohama, Meeting Room 514. > > Davey > >> ? 2015?8?14??18:33?Davey Song > ??? >> >> Dear Colleagues, >> >> We are going to be holding a Yeti DNS workshop before IETF 94 in >> Yokohama. >> >> Date: 2015-10-31 (Saturday before IETF 94) >> Time: 10:00-16:00 (to be confirmed) >> Location: Pacifico Yokohama (IETF venue, to be confirmed) >> >> It will be a half-day workshop, covering the status of the project at >> that time. We expect reports on the project status from the >> coordinators, discussion of experiments and other findings, as well as >> both detailed and high-level plans. Topics outside of the Yeti DNS >> project itself are also appropriate, if they are about related to the >> work and future DNS Root service. A full agenda will be published in advance. >> >> RSVP: Please reply offline let us (coordinators at lists.yeti-dns.org ) know >> if you are planning on attending. Also do please send any topic >> suggestions or other proposals. >> >> Note that while this is Halloween, costumes are optional. >> >> --Yeti DNS project coordinators >> >> ------------------------------ >> Davey Song(???) >> BII Lab >> songlinjian at gmail.com >> >> > > ------------------------------ > Davey Song(???) > BII Lab > songlinjian at gmail.com > > ------------------------------ Davey Song(???) BII Lab songlinjian at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at redbarn.org Tue Oct 20 04:19:16 2015 From: paul at redbarn.org (Paul Vixie) Date: Mon, 19 Oct 2015 21:19:16 -0700 Subject: [dns-operations] Always replying to UDP requests with TC=1, good practice or not In-Reply-To: <20151019204934.972BE3AC4575@rock.dv.isc.org> References: <20151018153341.GA11366@sources.org> <2246785.9G8M1MizFP@linux-rfx1> <20151019204934.972BE3AC4575@rock.dv.isc.org> Message-ID: <20358799.JhX2UFCgWB@linux-rfx1> On Tuesday, October 20, 2015 07:49:34 Mark Andrews wrote: > > With EDNS COOKIES one can require a good server cookie before > providing more of a answer than just BADCOOKIE over UDP. This is > similar in nature to always sending TC=1 but keeps the traffic on > UDP rather than switching the traffic to TCP. It also doesn't > require the authoritative server to keep any per client state. fwiw, i love this approach. DNS RRL is a workaround, nothing more. note, though: http://www.christian-rossow.de/publications/tcpamplification-woot2014.pdf in this paper, the authors explain why the obligation in TCP to retransmit un- acked data should not have covered the unconnected state. SYN's will be retransmitted, so SYN-ACK's need not have been subject to retransmission. so there are billions of connected devices now willing to reflect with an amplification between 5X and 50X (there was no standard for this number), which devices are (a) globally reachable via the internet and (b) unpatchable and (c) immortal. so, we should get DNS cookies implemented, in order that the reflective amplifying spoofed-source attackers can switch to TCP SYN instead. -- Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From dot at dotat.at Wed Oct 21 15:30:50 2015 From: dot at dotat.at (Tony Finch) Date: Wed, 21 Oct 2015 16:30:50 +0100 Subject: [dns-operations] Cutting a zone with DNSSEC Message-ID: Does anyone know of any good how-to guides for cutting an existing zone which already has records in use below the new delegation point? I've written some notes on what we are doing this week (link below) but I'd like to hear what others have done. In particular I'm wondering about how tightly consistent the authoritative servers for the parent zone need to be. Not a problem for us, fortunately. http://fanf.livejournal.com/138451.html Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: In south, cyclonic 6 to gale 8, becoming northeasterly 4 or 5. In north, northeasterly 5 to 7, occasionally gale 8 at first. In south, rough or very rough, becoming slight or moderate later. in north, rough or very rough, becoming slight or moderate later. In south, showers, thundery at first. In north, fair. In south, good, occasionally poor at first. In north, good. From marka at isc.org Wed Oct 21 20:35:34 2015 From: marka at isc.org (Mark Andrews) Date: Thu, 22 Oct 2015 07:35:34 +1100 Subject: [dns-operations] Cutting a zone with DNSSEC In-Reply-To: Your message of "Wed, 21 Oct 2015 16:30:50 +0100." References: Message-ID: <20151021203534.738143ADCF3E@rock.dv.isc.org> Method 1: Just lower the ttl of all responses for the namespace being delegated including negative ones. This ttl is the potential validation failure blip. e.g. 30-60 seconds Wait for all reponses with the original ttl to flush from the cache. Have the child zone on different servers to the parent if possible already signed and answering. Introduce the zone cut and update the signatures of the parent zone. Restore ttls to parent zone, remove oculted data you want to remove. Method 2: Lower the negative ttl. Copy the data from the namespace to the child zone to be. Sign the child zone. Add the signatures from the child zone to the parent zone. Add the signatures from the parent zone to the child zone. This way both zone will be serving the same sets of signatures. Serve the child zone on different servers if possible. Introduce the zone cut and re-sign the delegation point. (If you using the same servers combine these as best as possible) Wait for the ttls to expire and clean up the copied ttls and occulted data. In both methods it is important to lower the negative ttls to minimize disruption. Mark In message , Tony F inch writes: > Does anyone know of any good how-to guides for cutting an existing zone > which already has records in use below the new delegation point? I've > written some notes on what we are doing this week (link below) but I'd > like to hear what others have done. In particular I'm wondering about how > tightly consistent the authoritative servers for the parent zone need to > be. Not a problem for us, fortunately. > > http://fanf.livejournal.com/138451.html > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Trafalgar: In south, cyclonic 6 to gale 8, becoming northeasterly 4 or 5. In > north, northeasterly 5 to 7, occasionally gale 8 at first. In south, rough or > very rough, becoming slight or moderate later. in north, rough or very rough, > becoming slight or moderate later. In south, showers, thundery at first. In > north, fair. In south, good, occasionally poor at first. In north, good. > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From dot at dotat.at Thu Oct 22 13:29:32 2015 From: dot at dotat.at (Tony Finch) Date: Thu, 22 Oct 2015 14:29:32 +0100 Subject: [dns-operations] Cutting a zone with DNSSEC In-Reply-To: <20151021203534.738143ADCF3E@rock.dv.isc.org> References: <20151021203534.738143ADCF3E@rock.dv.isc.org> Message-ID: Mark Andrews wrote: > Thanks for the advice. The zone surgery went well :-) > Method 1: > Just lower the ttl of all responses for the namespace being > delegated including negative ones. This ttl is the potential > validation failure blip. e.g. 30-60 seconds Presumably that assumes you have fast authoritative propagation. (We do, so this worked well for us.) I guess that if you have slow authoritative servers then you would have to do the signature juggling you outlined below. I don't think that would be fun at all :-) > Method 2: > > Lower the negative ttl. > > Copy the data from the namespace to the child zone to be. > > Sign the child zone. > > Add the signatures from the child zone to the parent zone. > Add the signatures from the parent zone to the child zone. > > This way both zone will be serving the same sets of signatures. > > Serve the child zone on different servers if possible. > Introduce the zone cut and re-sign the delegation point. > (If you using the same servers combine these as best as > possible) > > Wait for the ttls to expire and clean up the copied ttls > and occulted data. > > In both methods it is important to lower the negative ttls to > minimize disruption. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty, Forth: West or southwest 7 to severe gale 9, decreasing 5 or 6 later. Rough or very rough, becoming high for a time in north Forties. Showers at first. Moderate or good. From marka at isc.org Thu Oct 22 21:36:09 2015 From: marka at isc.org (Mark Andrews) Date: Fri, 23 Oct 2015 08:36:09 +1100 Subject: [dns-operations] Cutting a zone with DNSSEC In-Reply-To: Your message of "Thu, 22 Oct 2015 14:29:32 +0100." References: <20151021203534.738143ADCF3E@rock.dv.isc.org> Message-ID: <20151022213609.A4F243B05D65@rock.dv.isc.org> In message , Tony Finch writes: > Mark Andrews wrote: > > > > Thanks for the advice. The zone surgery went well :-) > > > Method 1: > > Just lower the ttl of all responses for the namespace being > > delegated including negative ones. This ttl is the potential > > validation failure blip. e.g. 30-60 seconds > > Presumably that assumes you have fast authoritative propagation. > (We do, so this worked well for us.) > > I guess that if you have slow authoritative servers then you would have to > do the signature juggling you outlined below. I don't think that would be > fun at all :-) No. The validator should try other servers if the validation fails. It just does more work until all the servers are up to date. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From daniel.stirnimann at switch.ch Fri Oct 23 06:31:40 2015 From: daniel.stirnimann at switch.ch (Daniel Stirnimann) Date: Fri, 23 Oct 2015 08:31:40 +0200 Subject: [dns-operations] EDNS0 client-subnet option from Google Resolvers Message-ID: <5629D44C.4010708@switch.ch> Hello I was wondering why Google DNS (8.8.8.8) resolvers don't use EDNS0 client-subnet option in every request towards our authoritative name server. The following table shows a break down of google resolvers and the number of EDNS0 client-subnet queries vs. none client-subnet queries. count ,srcaddr ,opt-code ,opt-len 14731 ,"74.125.176.176",0 ,0 40 ,"74.125.176.176",8 ,7 14133 ,"74.125.176.177",0 ,0 28 ,"74.125.176.177",8 ,7 14382 ,"74.125.176.178",0 ,0 28 ,"74.125.176.178",8 ,7 14342 ,"74.125.176.179",0 ,0 35 ,"74.125.176.179",8 ,7 13743 ,"74.125.176.180",0 ,0 25 ,"74.125.176.180",8 ,7 15226 ,"74.125.176.181",0 ,0 31 ,"74.125.176.181",8 ,7 14331 ,"74.125.176.182",0 ,0 29 ,"74.125.176.182",8 ,7 15568 ,"74.125.176.183",0 ,0 28 ,"74.125.176.183",8 ,7 The number of queries with EDNS0 client-subnet is rather low. Is this because the resolver figured out that our authoritative name server is not responding this option, so they don't send it every time but just from time to time to check if we support it now? Daniel -- SWITCH Daniel Stirnimann, SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 16 24 daniel.stirnimann at switch.ch, http://www.switch.ch From daniel.stirnimann at switch.ch Fri Oct 23 07:18:44 2015 From: daniel.stirnimann at switch.ch (Daniel Stirnimann) Date: Fri, 23 Oct 2015 09:18:44 +0200 Subject: [dns-operations] EDNS0 client-subnet option from Google Resolvers In-Reply-To: <5629D44C.4010708@switch.ch> References: <5629D44C.4010708@switch.ch> Message-ID: <5629DF54.5040500@switch.ch> > Is this > because the resolver figured out that our authoritative name server is > not responding this option, so they don't send it every time but just > from time to time to check if we support it now? Looks like these are indeed probing requests. Found the following: "This is implemented by probing nameservers at a low rate with ECS queries and caching the ECS capability for each nameserver. Therefore if your nameservers do not support ECS, they may still receive a few ECS queries occasionally. And if your nameservers just started to support ECS, it may take us several hours to detect the change and start to send ECS queries to them." https://groups.google.com/forum/?hl=en#!topic/public-dns-announce/67oxFjSLeUM Daniel -- SWITCH Daniel Stirnimann, SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 16 24 daniel.stirnimann at switch.ch, http://www.switch.ch From marka at isc.org Fri Oct 23 20:36:01 2015 From: marka at isc.org (Mark Andrews) Date: Sat, 24 Oct 2015 07:36:01 +1100 Subject: [dns-operations] EDNS0 client-subnet option from Google Resolvers In-Reply-To: Your message of "Fri, 23 Oct 2015 09:18:44 +0200." <5629DF54.5040500@switch.ch> References: <5629D44C.4010708@switch.ch> <5629DF54.5040500@switch.ch> Message-ID: <20151023203601.A11F13B11711@rock.dv.isc.org> In message <5629DF54.5040500 at switch.ch>, Daniel Stirnimann writes: > > Is this > > because the resolver figured out that our authoritative name server is > > not responding this option, so they don't send it every time but just > > from time to time to check if we support it now? > > Looks like these are indeed probing requests. Found the following: > > "This is implemented by probing nameservers at a low rate with ECS > queries and caching the ECS capability for each nameserver. Therefore if > your nameservers do not support ECS, they may still receive a few ECS > queries occasionally. And if your nameservers just started to support > ECS, it may take us several hours to detect the change and start to send > ECS queries to them." > > https://groups.google.com/forum/?hl=en#!topic/public-dns-announce/67oxFjSLeUM > > Daniel > -- > SWITCH > Daniel Stirnimann, SWITCH-CERT > Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland > phone +41 44 268 15 15, direct +41 44 268 16 24 > daniel.stirnimann at switch.ch, http://www.switch.ch > _______________________________________________ > dns-operations mailing list > dns-operations at lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > dns-jobs mailing list > https://lists.dns-oarc.net/mailman/listinfo/dns-jobs I hope they also graph the support level along with the error levels they see. It would be interesting to see how they compare to the unknown option datasets at https://ednscomp.isc.org/compliance/summary.html Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From edmonds at mycre.ws Fri Oct 23 20:52:23 2015 From: edmonds at mycre.ws (Robert Edmonds) Date: Fri, 23 Oct 2015 16:52:23 -0400 Subject: [dns-operations] EDNS0 client-subnet option from Google Resolvers In-Reply-To: <5629DF54.5040500@switch.ch> References: <5629D44C.4010708@switch.ch> <5629DF54.5040500@switch.ch> Message-ID: <20151023205223.GA26331@mycre.ws> Daniel Stirnimann wrote: > > Is this > > because the resolver figured out that our authoritative name server is > > not responding this option, so they don't send it every time but just > > from time to time to check if we support it now? > > Looks like these are indeed probing requests. Found the following: > > "This is implemented by probing nameservers at a low rate with ECS > queries and caching the ECS capability for each nameserver. Therefore if > your nameservers do not support ECS, they may still receive a few ECS > queries occasionally. And if your nameservers just started to support > ECS, it may take us several hours to detect the change and start to send > ECS queries to them." There's also https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-04#section-12.1, which I believe is supposed to be describing the Google implementation. -- Robert Edmonds From dot at dotat.at Mon Oct 26 15:34:20 2015 From: dot at dotat.at (Tony Finch) Date: Mon, 26 Oct 2015 15:34:20 +0000 Subject: [dns-operations] Cutting a zone with DNSSEC In-Reply-To: <20151022213609.A4F243B05D65@rock.dv.isc.org> References: <20151021203534.738143ADCF3E@rock.dv.isc.org> <20151022213609.A4F243B05D65@rock.dv.isc.org> Message-ID: Mark Andrews wrote: > > No. The validator should try other servers if the validation fails. > It just does more work until all the servers are up to date. OK, that's reassuring. And it's another point in favour of your argument that validating stubs should use CD=0, because CD=1 suppresses the recursive server's efforts to work around this kind of partial temporary breakage. Tony. -- f.anthony.n.finch http://dotat.at/ Irish Sea, Shannon, Rockall, Malin: South or southeast 5 to 7, occasionally gale 8 at first. Rough or very rough, occasionally high in Shannon and Rockall at first. Rain or showers. Good, occasionally poor. From marka at isc.org Mon Oct 26 20:06:44 2015 From: marka at isc.org (Mark Andrews) Date: Tue, 27 Oct 2015 07:06:44 +1100 Subject: [dns-operations] Cutting a zone with DNSSEC In-Reply-To: Your message of "Mon, 26 Oct 2015 15:34:20 -0000." References: <20151021203534.738143ADCF3E@rock.dv.isc.org> <20151022213609.A4F243B05D65@rock.dv.isc.org> Message-ID: <20151026200644.21A373B24DFF@rock.dv.isc.org> In message , Tony F inch writes: > Mark Andrews wrote: > > > > No. The validator should try other servers if the validation fails. > > It just does more work until all the servers are up to date. > > OK, that's reassuring. > > And it's another point in favour of your argument that validating stubs > should use CD=0, because CD=1 suppresses the recursive server's efforts > to work around this kind of partial temporary breakage. Yes. RFC 6840 is just plain wrong to say always send CD=1 and named doesn't. Mark > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Irish Sea, Shannon, Rockall, Malin: South or southeast 5 to 7, occasionally > gale 8 at first. Rough or very rough, occasionally high in Shannon and Rockal > l > at first. Rain or showers. Good, occasionally poor. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org