Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
Anyway.. I found out what the problem is... they don't reply to dnssec enabled requests... $ dig +short @ns33.domaincontrol.com. replacementservices.com. 72.32.12.235 $ dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. ;; connection timed out; no servers could be reached wanna boycott godaddy? -- LP, Rok smime.p7s Description: S/MIME Cryptographic Signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
On Mon, 21 Jun 2010, Rok Potočnik wrote: Anyway.. I found out what the problem is... they don't reply to dnssec enabled requests... $ dig +short @ns33.domaincontrol.com. replacementservices.com. 72.32.12.235 $ dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. ;; connection timed out; no servers could be reached wanna boycott godaddy? I don't see that issue: [p...@bofh ~]$ dig +norecurse +dnssec -t ns replacementservices.com. @ns33.domaincontrol.com. ; <<>> DiG 9.6.2-P2-RedHat-9.6.2-4.P2.fc12 <<>> +norecurse +dnssec -t ns replacementservices.com. @ns33.domaincontrol.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35398 ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;replacementservices.com. IN NS ;; ANSWER SECTION: replacementservices.com. 3600 IN NS ns33.domaincontrol.com. replacementservices.com. 3600 IN NS ns34.domaincontrol.com. ;; Query time: 29 msec ;; SERVER: 216.69.185.17#53(216.69.185.17) ;; WHEN: Mon Jun 21 11:58:31 2010 ;; MSG SIZE rcvd: 93 Paul ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
In message <4c1f85ef.5070...@rula.net>, =?UTF-8?B?Um9rIFBvdG/EjW5paw==?= writes : > Anyway.. I found out what the problem is... they don't reply to dnssec > enabled requests... > > $ dig +short @ns33.domaincontrol.com. replacementservices.com. > 72.32.12.235 > > $ dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. > ;; connection timed out; no servers could be reached > > wanna boycott godaddy? > > -- > LP, Rok They DO respond. Look at your firewall. % dig +short @ns33.domaincontrol.com. replacementservices.com. 72.32.12.235 % dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. 72.32.12.235 % Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
Mark Andrews writes: > > In message <4c1f85ef.5070...@rula.net>, =?UTF-8?B?Um9rIFBvdG/EjW5paw==?= writ > es > : > > Anyway.. I found out what the problem is... they don't reply to dnssec > > enabled requests... > > > > $ dig +short @ns33.domaincontrol.com. replacementservices.com. > > 72.32.12.235 > > > > $ dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. > > ;; connection timed out; no servers could be reached > > > > wanna boycott godaddy? > > > > -- > > LP, Rok > > They DO respond. Look at your firewall. > > % dig +short @ns33.domaincontrol.com. replacementservices.com. > 72.32.12.235 > % dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. > 72.32.12.235 > % > > Mark I suspect that your firewall is dropping replies to EDNS queries that *don't* include the OPT record (i.e. they are plain DNS not EDNS responses). Note that there was no OPT record in the reply. ; <<>> DiG 9.3.6-P1 <<>> +dnssec @ns33.domaincontrol.com. replacementservices.com. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36916 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;replacementservices.com. IN A ;; ANSWER SECTION: replacementservices.com. 3600 IN A 72.32.12.235 ;; AUTHORITY SECTION: replacementservices.com. 3600 IN NS ns33.domaincontrol.com. replacementservices.com. 3600 IN NS ns34.domaincontrol.com. ;; Query time: 184 msec ;; SERVER: 216.69.185.17#53(216.69.185.17) ;; WHEN: Tue Jun 22 10:12:45 2010 ;; MSG SIZE rcvd: 109 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
In message <201006220016.o5m0g7j4024...@drugs.dv.isc.org>, Mark Andrews writes: > > Mark Andrews writes: > > > > In message <4c1f85ef.5070...@rula.net>, =?UTF-8?B?Um9rIFBvdG/EjW5paw==?= wr > it > > es > > : > > > Anyway.. I found out what the problem is... they don't reply to dnssec > > > enabled requests... > > > > > > $ dig +short @ns33.domaincontrol.com. replacementservices.com. > > > 72.32.12.235 > > > > > > $ dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. > > > ;; connection timed out; no servers could be reached > > > > > > wanna boycott godaddy? > > > > > > -- > > > LP, Rok > > > > They DO respond. Look at your firewall. > > > > % dig +short @ns33.domaincontrol.com. replacementservices.com. > > 72.32.12.235 > > % dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. > > 72.32.12.235 > > % > > > > Mark > > I suspect that your firewall is dropping replies to EDNS queries > that *don't* include the OPT record (i.e. they are plain DNS not > EDNS responses). Note that there was no OPT record in the reply. > > ; <<>> DiG 9.3.6-P1 <<>> +dnssec @ns33.domaincontrol.com. replacementservices > .com. > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36916 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;replacementservices.com. IN A > > ;; ANSWER SECTION: > replacementservices.com. 3600 IN A 72.32.12.235 > > ;; AUTHORITY SECTION: > replacementservices.com. 3600 IN NS ns33.domaincontrol.com. > replacementservices.com. 3600 IN NS ns34.domaincontrol.com. > > ;; Query time: 184 msec > ;; SERVER: 216.69.185.17#53(216.69.185.17) > ;; WHEN: Tue Jun 22 10:12:45 2010 > ;; MSG SIZE rcvd: 109 > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users You can stop named making EDNS queries to these servers using the server statement while you fix your firewall. e.g. server 216.69.185.17 { edns no; }; Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
On 22.6.2010 2:16, Mark Andrews wrote: I suspect that your firewall is dropping replies to EDNS queries that *don't* include the OPT record (i.e. they are plain DNS not EDNS responses). Note that there was no OPT record in the reply. I hardly think that my firewall configuration is faulty because I tried it using different ISPs and even running "iptables -I INPUT -p udp --sport 53 -j ACCEPT" on all servers. Apparently it's a buggy firewall somewhere between the *.domaincontrol.com and my servers... The ISPs I tried are using either Telia or Geant for international uplinks. I'd like to emphasize that quite a lot of other domains on other servers get resolved and running "dig +short rs.dns-oarc.net txt" returns high (3843) values. ISP 1# traceroute ns33.domaincontrol.com traceroute to ns33.domaincontrol.com (216.69.185.17), 30 hops max, 38 byte packets 1 BSN-access.dsl.siol.net (213.250.19.90) 26.935 ms 17.750 ms 16.713 ms 2 * * 95.176.241.126 (95.176.241.126) 17.416 ms 3 95.176.253.9 (95.176.253.9) 17.826 ms 75.801 ms 16.747 ms 4 win-b2-link.telia.net (213.248.102.177) 24.095 ms 24.004 ms 23.846 ms 5 prag-bb1-link.telia.net (80.91.246.50) 28.999 ms 29.884 ms 30.308 ms 6 ffm-bb1-link.telia.net (80.91.246.14) 48.668 ms 70.800 ms 134.729 ms 7 ffm-b7-link.telia.net (80.91.254.249) 54.238 ms ffm-b7-link.telia.net (80.91.251.52) 47.574 ms ffm-b7-link.telia.net (80.91.254.93) 64.056 ms 8 globalcrossing-119012-ffm-b7.telia.net (213.248.103.42) 106.136 ms globalcrossing-ic-130855-ffm-b7.c.telia.net (213.248.89.182) 50.004 ms globalcrossing-119012-ffm-b7.telia.net (213.248.103.42) 67.012 ms 9 204.245.39.50 (204.245.39.50) 53.012 ms 53.129 ms 51.957 ms 10 ip-208-109-115-201.ip.secureserver.net (208.109.115.201) 52.958 ms 50.611 ms 53.910 ms 11 * * * 12 ip-208-109-115-202.ip.secureserver.net (208.109.115.202) 53.414 ms 50.891 ms 51.195 ms 13 ip-208-109-115-121.ip.secureserver.net (208.109.115.121) 52.730 ms 53.783 ms 52.695 ms 14 ip-208-109-115-218.ip.secureserver.net (208.109.115.218) 53.935 ms 52.908 ms 52.163 ms 15 ip-208-109-115-217.ip.secureserver.net (208.109.115.217) 52.694 ms 52.646 ms 51.930 ms 16 ip-208-109-113-62.ip.secureserver.net (208.109.113.62) 52.944 ms 51.881 ms 52.922 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * ISP 2# traceroute ns33.domaincontrol.com traceroute to ns33.domaincontrol.com (216.69.185.17), 30 hops max, 38 byte packets 1 93-103-0-1.gw.t-2.net (93.103.0.1) 9.030 ms 8.083 ms 8.160 ms 2 84-255-209-193.core.t-2.net (84.255.209.193) 8.374 ms 8.023 ms 7.974 ms 3 84-255-250-22.core.t-2.net (84.255.250.22) 7.968 ms 8.256 ms 8.224 ms 4 win-b2-link.telia.net (213.248.104.157) 11.738 ms 11.779 ms 11.723 ms 5 win-bb2-link.telia.net (80.91.246.198) 12.238 ms 12.327 ms 12.223 ms 6 ffm-bb2-link.telia.net (80.91.246.30) 25.486 ms 24.566 ms 24.715 ms 7 ffm-b7-link.telia.net (80.91.251.54) 24.993 ms ffm-b7-link.telia.net (80.91.254.253) 30.086 ms ffm-b7-link.telia.net (80.91.254.101) 24.845 ms 8 globalcrossing-ic-130855-ffm-b7.c.telia.net (213.248.89.182) 25.251 ms 24.846 ms 24.977 ms 9 204.245.39.50 (204.245.39.50) 34.239 ms 34.865 ms 34.478 ms 10 ip-208-109-115-201.ip.secureserver.net (208.109.115.201) 34.735 ms 34.950 ms 34.478 ms 11 * * * 12 ip-208-109-115-202.ip.secureserver.net (208.109.115.202) 34.793 ms 35.214 ms 34.732 ms 13 ip-208-109-115-121.ip.secureserver.net (208.109.115.121) 34.730 ms 34.768 ms 34.729 ms 14 ip-208-109-115-218.ip.secureserver.net (208.109.115.218) 34.483 ms 35.016 ms 34.479 ms 15 ip-208-109-115-217.ip.secureserver.net (208.109.115.217) 34.718 ms 109.990 ms 34.481 ms 16 ip-208-109-113-62.ip.secureserver.net (208.109.113.62) 34.476 ms 34.501 ms 34.477 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * ISP 3# traceroute ns33.domaincontrol.com traceroute to ns33.domaincontrol.com (216.69.185.17), 30 hops max, 38 byte packets 1 * * * 2 BSN-6.siol.net (193.77.8.1) 61.959 ms 28.323 ms 26.930 ms 3 95.176.241.126 (95.176.241.126) 24.220 ms 23.460 ms 25.124 ms 4 * * * 5 rpttlj1-tk.arnes.si (193.2.33.34) 23.972 ms 24.332 ms 23.130 ms 6 rpttlj1-G0-1.arnes.si (193.2.33.33) 23.525 ms 22.670 ms 24.388 ms 7 rpttlj2-G4-1-0x100.arnes.si (193.2.31.65) 23.645 ms 23.202 ms 23.194 ms 8 lpttlj2-V788.arnes.si (193.2.31.138) 23.371 ms 23.714 ms 23.366 ms 9 larnes6-V65.arnes.si (193.2.30.65) 22.935 ms 22.920 ms 23.679 ms 10 rarnes1-X0-0-0x101.arnes.si (212.235.160.241) 23.134 ms 23.392 ms 22.900 ms 11 arnes.rt1.vie.at.geant2.net (62.40.124.5) 31.331 ms 30.380 ms 30.857 ms 12 tenGigabitEthernet1-3.ar2.VIE1.gblx.net (64.214.145.145) 36.976 ms 141.477 ms 207.660 ms 13 204.245.39
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
On Mon, Jun 21, 2010 at 05:31:59PM +0200, Rok Poto??nik wrote: > Anyway.. I found out what the problem is... they don't reply to dnssec > enabled requests... > > $ dig +short @ns33.domaincontrol.com. replacementservices.com. > 72.32.12.235 > > $ dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. > ;; connection timed out; no servers could be reached > > wanna boycott godaddy? > Actually, they don't support EDNS either, so you'll get timeouts even without DNSSEC: er...@orange:~% dig +short +edns=0 @ns33.domaincontrol.com. replacementservices.com. ;; connection timed out; no servers could be reached er...@orange:~% dig +short @ns33.domaincontrol.com. replacementservices.com. 72.32.12.235 Note that Bind 9.5 fixed the timeout issue by resending it as a plain request, you may want to upgrade your recursors if they are still on 9.4. See last item in the list: https://www.isc.org/software/bind/new-features/9.5 -erwin -- Erwin Lansing (o_ _o) http://droso.org Ceterum censeo \\\_\ /_/// Carthaginem esse delendam<) (>er...@lansing.dk pgpAUKDxWYIpt.pgp Description: PGP signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
In message , Piff writes: > Mark, > > more than once you have blamed firewal but I have tested without > firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig +dnssec". Wrong. The nameserver DO answer these queries. # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. ; <<>> DiG 9.3.6-P1 <<>> +dnssec @ns33.domaincontrol.com. replacementservices.com. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41760 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;replacementservices.com. IN A ;; ANSWER SECTION: replacementservices.com. 3600 IN A 72.32.12.235 ;; AUTHORITY SECTION: replacementservices.com. 3600 IN NS ns33.domaincontrol.com. replacementservices.com. 3600 IN NS ns34.domaincontrol.com. ;; Query time: 346 msec ;; SERVER: 216.69.185.17#53(216.69.185.17) ;; WHEN: Wed Jun 23 17:39:43 2010 ;; MSG SIZE rcvd: 109 # Since you are not getting answers then there is a problem between you and the nameservers in question and as just about every one else is getting answers as well this puts the problem close to you. i.e. Your network or your ISP's network. Something on the path is doing DPI tests and is rejecting the response. Do you have a NAT that does DPI? > The real problem is bind. Freshly reloaded bind will do a query with > OPT EDNS0 set and after a timeout retry the query without OPT EDNS0 > but after some time the queries are only with OPT EDNS0 set. Why? Why no > fallback? My machines are running version 9.6-ESV-R1 and 9.4-ESV-R2. It does fallback to plain DNS. > -Sai -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
On Wed, Jun 23, 2010 at 05:51:24PM +1000, Mark Andrews wrote: > > In message , > Piff > writes: > > Mark, > > > > more than once you have blamed firewal but I have tested without > > firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig +dnssec". > > Wrong. The nameserver DO answer these queries. Right, unfortunately. All is fine on a freshly reloaded bind, but after a while no answers are seen. This is on Bind 9.4, 9.5 and 9.6. > > # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. > > ; <<>> DiG 9.3.6-P1 <<>> +dnssec @ns33.domaincontrol.com. > replacementservices.com. > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41760 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;replacementservices.com. IN A > > ;; ANSWER SECTION: > replacementservices.com. 3600 IN A 72.32.12.235 > > ;; AUTHORITY SECTION: > replacementservices.com. 3600 IN NS ns33.domaincontrol.com. > replacementservices.com. 3600 IN NS ns34.domaincontrol.com. > > ;; Query time: 346 msec > ;; SERVER: 216.69.185.17#53(216.69.185.17) > ;; WHEN: Wed Jun 23 17:39:43 2010 > ;; MSG SIZE rcvd: 109 > > # # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. ; <<>> DiG 9.6.1-P3 <<>> +dnssec @ns33.domaincontrol.com. replacementservices.com. ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached > > Since you are not getting answers then there is a problem between > you and the nameservers in question and as just about every one > else is getting answers as well this puts the problem close to you. > i.e. Your network or your ISP's network. Something on the path is > doing DPI tests and is rejecting the response. Do you have a NAT > that does DPI? No firewall, DPI, NAT or any form of filtering involved on our side, direct peering with GLBX. -erwin -- Erwin Lansing (o_ _o) http://droso.org Ceterum censeo \\\_\ /_/// Carthaginem esse delendam<) (>er...@lansing.dk pgpLyxBNei27V.pgp Description: PGP signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
> On Wed, Jun 23, 2010 at 05:51:24PM +1000, Mark Andrews wrote: > > Wrong. The nameserver DO answer these queries. On 23.06.10 11:01, Erwin Lansing wrote: > Right, unfortunately. All is fine on a freshly reloaded bind, but after > a while no answers are seen. This is on Bind 9.4, 9.5 and 9.6. how do you think ns33.domaincontrol.com. detects your freshly reloaded bind to know when to answer and when not? > # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. > > ; <<>> DiG 9.6.1-P3 <<>> +dnssec @ns33.domaincontrol.com. > replacementservices.com. > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached works for me, works for mark... the problem is apparently not on their side. I have tried more times when reading this thread. I'm also curious where the problem could be. and, btw, your bind is _not_ involved when you use "dig @server" > > Since you are not getting answers then there is a problem between > > you and the nameservers in question and as just about every one > > else is getting answers as well this puts the problem close to you. > > i.e. Your network or your ISP's network. Something on the path is > > doing DPI tests and is rejecting the response. Do you have a NAT > > that does DPI? > > No firewall, DPI, NAT or any form of filtering involved on our side, > direct peering with GLBX. did you try to recheck? What's your MTU? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. You have the right to remain silent. Anything you say will be misquoted, then used against you. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
On Wed, Jun 23, 2010 at 11:23:51AM +0200, Matus UHLAR - fantomas wrote: > > works for me, works for mark... the problem is apparently not on their side. > I have tried more times when reading this thread. I'm also curious where the > problem could be. > All I know is that "something" changed last week and it stopped working for several people all over the world on completely unrelated networks and setups. I'm just one of them. Occams razor says that the most likely cause is at domaincontrol as they are the only common factor in all of these. -erwin -- Erwin Lansing (o_ _o) http://droso.org Ceterum censeo \\\_\ /_/// Carthaginem esse delendam<) (>er...@lansing.dk pgpukzvLmo12P.pgp Description: PGP signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
On 23.06.2010 / 17:51:24 +1000, Mark Andrews wrote: > > In message , > Piff > writes: > > Mark, > > > > more than once you have blamed firewal but I have tested without > > firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig +dnssec". > > Wrong. The nameserver DO answer these queries. > > # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. > > ; <<>> DiG 9.3.6-P1 <<>> +dnssec @ns33.domaincontrol.com. > replacementservices.com. > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41760 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;replacementservices.com. IN A > > ;; ANSWER SECTION: > replacementservices.com. 3600 IN A 72.32.12.235 > > ;; AUTHORITY SECTION: > replacementservices.com. 3600 IN NS ns33.domaincontrol.com. > replacementservices.com. 3600 IN NS ns34.domaincontrol.com. > This dig query timeouts on my side, checked from 3 different IPs from 3 different AS (autonomous systems). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
Am Wed, 23 Jun 2010 11:01:29 +0200 schrieb Erwin Lansing : > On Wed, Jun 23, 2010 at 05:51:24PM +1000, Mark Andrews wrote: > > > > In message > > , > > Piff writes: > > > Mark, > > > > > > more than once you have blamed firewal but I have tested without > > > firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig > > > +dnssec". > > > > Wrong. The nameserver DO answer these queries. > > Right, unfortunately. All is fine on a freshly reloaded bind, but > after a while no answers are seen. This is on Bind 9.4, 9.5 and 9.6. > > > > # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. > > > > ; <<>> DiG 9.3.6-P1 <<>> +dnssec @ns33.domaincontrol.com. > > replacementservices.com. ; (1 server found) > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41760 > > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;replacementservices.com. IN A > > > > ;; ANSWER SECTION: > > replacementservices.com. 3600 IN A 72.32.12.235 > > > > ;; AUTHORITY SECTION: > > replacementservices.com. 3600 IN NS > > ns33.domaincontrol.com. replacementservices.com. 3600 IN > > NS ns34.domaincontrol.com. > > > > ;; Query time: 346 msec > > ;; SERVER: 216.69.185.17#53(216.69.185.17) > > ;; WHEN: Wed Jun 23 17:39:43 2010 > > ;; MSG SIZE rcvd: 109 > > > > # > > # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. > > ; <<>> DiG 9.6.1-P3 <<>> +dnssec @ns33.domaincontrol.com. > replacementservices.com. > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > > > > > Since you are not getting answers then there is a problem between > > you and the nameservers in question and as just about every one > > else is getting answers as well this puts the problem close to you. > > i.e. Your network or your ISP's network. Something on the path is > > doing DPI tests and is rejecting the response. Do you have a NAT > > that does DPI? > > No firewall, DPI, NAT or any form of filtering involved on our side, > direct peering with GLBX. > > -erwin > Since it's working quite okay for several locations on here, the problem may be found somewhere in between sites. I personally don't get any failures with the dig statement from above no matter how often I try. Looking at a tracepath the last hop I see seems to be an edge router of AboveNet Communications. tracepath ns33.domaincontrol.com 1: eve.the-damian.de (195.180.9.245) 0.132ms pmtu 1500 1: vl100.cr20.isham.de.easynet.net (195.180.9.252)0.888ms 1: vl100.cr20.isham.de.easynet.net (195.180.9.252)0.830ms 2: ge1-1.br2.isham.de.easynet.net (212.224.4.90) 0.857ms 3: ge3-0-2.gr10.isham.de.easynet.net (87.86.71.244) 0.762ms 4: te0-0-0-0.er10.ixfra.de.easynet.net (87.86.77.247)10.931ms asymm 7 5: xe-1-2-0.mpr1.fra4.de.above.net (80.81.194.26)10.407ms asymm 7 6: xe-1-1-0.mpr1.cdg12.fr.above.net (64.125.24.6)22.851ms 7: xe-4-0-0.mpr1.lhr3.uk.above.net (64.125.31.249) 28.677ms asymm 9 8: so-0-1-0.mpr2.dca2.us.above.net (64.125.27.165) 98.858ms asymm 9 9: xe-0-3-0.cr2.dca2.us.above.net (64.125.29.25)102.567ms asymm 10 10: xe-0-1-0.er2.dca2.us.above.net (64.125.27.29) 98.730ms asymm 11 11: xe-1-1-0.er2.iad10.above.net (64.125.26.242) 99.116ms asymm 13 12: no reply 13: no reply 14: no reply 15: no reply 16: no reply 17: no reply 18: no reply 19: no reply 20: no reply 21: no reply 22: no reply 23: no reply 24: no reply 25: no reply 26: no reply 27: no reply 28: no reply 29: no reply 30: no reply 31: no reply Too many hops: pmtu 1500 Resume: pmtu 1500 Ciao Torsten ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
On 23.06.10 14:41, Torsten wrote: > Since it's working quite okay for several locations on here, the > problem may be found somewhere in between sites. > > I personally don't get any failures with the dig statement from above > no matter how often I try. > > Looking at a tracepath the last hop I see seems to be an edge router of > AboveNet Communications. my tracepath ends at abovenet too and it works. The only trace I've seen in logs ened at secureserver.net. Maybe a routing problem? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I wonder how much deeper the ocean would be without sponges. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
On Jun 23, 2010, at 2:41 PM, Torsten wrote: Am Wed, 23 Jun 2010 11:01:29 +0200 schrieb Erwin Lansing : On Wed, Jun 23, 2010 at 05:51:24PM +1000, Mark Andrews wrote: In message , Piff writes: Mark, more than once you have blamed firewal but I have tested without firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig +dnssec". Wrong. The nameserver DO answer these queries. Right, unfortunately. All is fine on a freshly reloaded bind, but after a while no answers are seen. This is on Bind 9.4, 9.5 and 9.6. # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. ; <<>> DiG 9.3.6-P1 <<>> +dnssec @ns33.domaincontrol.com. replacementservices.com. ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41760 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;replacementservices.com. IN A ;; ANSWER SECTION: replacementservices.com. 3600 IN A 72.32.12.235 ;; AUTHORITY SECTION: replacementservices.com. 3600 IN NS ns33.domaincontrol.com. replacementservices.com. 3600 IN NS ns34.domaincontrol.com. ;; Query time: 346 msec ;; SERVER: 216.69.185.17#53(216.69.185.17) ;; WHEN: Wed Jun 23 17:39:43 2010 ;; MSG SIZE rcvd: 109 # # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. ; <<>> DiG 9.6.1-P3 <<>> +dnssec @ns33.domaincontrol.com. replacementservices.com. ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached Since you are not getting answers then there is a problem between you and the nameservers in question and as just about every one else is getting answers as well this puts the problem close to you. i.e. Your network or your ISP's network. Something on the path is doing DPI tests and is rejecting the response. Do you have a NAT that does DPI? No firewall, DPI, NAT or any form of filtering involved on our side, direct peering with GLBX. -erwin Since it's working quite okay for several locations on here, the problem may be found somewhere in between sites. I personally don't get any failures with the dig statement from above no matter how often I try. Me neither! Me neither! I also goes through AboveNet. W Looking at a tracepath the last hop I see seems to be an edge router of AboveNet Communications. tracepath ns33.domaincontrol.com 1: eve.the-damian.de (195.180.9.245) 0.132ms pmtu 1500 1: vl100.cr20.isham.de.easynet.net (195.180.9.252)0.888ms 1: vl100.cr20.isham.de.easynet.net (195.180.9.252)0.830ms 2: ge1-1.br2.isham.de.easynet.net (212.224.4.90) 0.857ms 3: ge3-0-2.gr10.isham.de.easynet.net (87.86.71.244) 0.762ms 4: te0-0-0-0.er10.ixfra.de.easynet.net (87.86.77.247)10.931ms asymm 7 5: xe-1-2-0.mpr1.fra4.de.above.net (80.81.194.26)10.407ms asymm 7 6: xe-1-1-0.mpr1.cdg12.fr.above.net (64.125.24.6)22.851ms 7: xe-4-0-0.mpr1.lhr3.uk.above.net (64.125.31.249) 28.677ms asymm 9 8: so-0-1-0.mpr2.dca2.us.above.net (64.125.27.165) 98.858ms asymm 9 9: xe-0-3-0.cr2.dca2.us.above.net (64.125.29.25)102.567ms asymm 10 10: xe-0-1-0.er2.dca2.us.above.net (64.125.27.29) 98.730ms asymm 11 11: xe-1-1-0.er2.iad10.above.net (64.125.26.242) 99.116ms asymm 13 12: no reply 13: no reply 14: no reply 15: no reply 16: no reply 17: no reply 18: no reply 19: no reply 20: no reply 21: no reply 22: no reply 23: no reply 24: no reply 25: no reply 26: no reply 27: no reply 28: no reply 29: no reply 30: no reply 31: no reply Too many hops: pmtu 1500 Resume: pmtu 1500 Ciao Torsten ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
On Wed, Jun 23, 2010 at 05:25:31PM +0200, Warren Kumari wrote: > >> > >> # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. > > > > Since it's working quite okay for several locations on here, the > > problem may be found somewhere in between sites. > > > > I personally don't get any failures with the dig statement from above > > no matter how often I try. > > > > > Me neither! Me neither! > > > I also goes through AboveNet. > A few more datapoints. I tried from 4 different AS numbers, two in Europe, two in the US, two routed via GLBX and two via above. Only one of them works (via Above). I'm at a loss at finding similarities between the non-working ones. -erwin -- Erwin Lansing (o_ _o) http://droso.org Ceterum censeo \\\_\ /_/// Carthaginem esse delendam<) (>er...@lansing.dk pgpaBQVUprNZb.pgp Description: PGP signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
Another datapoint: dig +dnssec @ns33.domaincontrol.com. replacementservices.com. ; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec @ns33.domaincontrol.com. replacementservices.com. ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached silver3:~ carlsen$ dig +dnssec replacementservices.com. ; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec replacementservices.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41422 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;replacementservices.com.INA ;; ANSWER SECTION: replacementservices.com. 3600INA72.32.12.235 ;; AUTHORITY SECTION: replacementservices.com. 3600INNSns33.domaincontrol.com. replacementservices.com. 3600INNSns34.domaincontrol.com. ;; ADDITIONAL SECTION: ns33.domaincontrol.com.3571INA216.69.185.17 ;; Query time: 3297 msec ;; SERVER: 192.168.15.2#53(192.168.15.2) ;; WHEN: Wed Jun 23 19:39:30 2010 ;; MSG SIZE rcvd: 136 silver3:~ carlsen$ dig +dnssec @ns34.domaincontrol.com. replacementservices.com. ; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec @ns34.domaincontrol.com. replacementservices.com. ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached This could look like a connectivity problem, one of the "interesting" ones. None of the official NSes will answer my dig, I do however get answers from my named. Dig +trace finds no answer: dig +dnssec +trace replacementservices.com. ; <<>> DiG 9.6.0-APPLE-P2 <<>> +dnssec +trace replacementservices.com. ;; global options: +cmd .331492INNSj.root-servers.net. .331492INNSd.root-servers.net. .331492INNSl.root-servers.net. .331492INNSh.root-servers.net. .331492INNSb.root-servers.net. .331492INNSi.root-servers.net. .331492INNSm.root-servers.net. .331492INNSg.root-servers.net. .331492INNSf.root-servers.net. .331492INNSe.root-servers.net. .331492INNSk.root-servers.net. .331492INNSc.root-servers.net. .331492INNSa.root-servers.net. .331492INRRSIGNS 8 0 518400 2010062800 2010062023 55138 . JItPMCeKTDTEjDyQgXLxSuxXEP01cA3k3tOlQDMhrCoDqZTrolGpMVAE dN2+7C9NAKW/dxRcoRvOAaSNRB+xQciHSHBygFaxcnprD+X6eMmS5PI3 wbDo5jyakN/yntzn1pNEoYSR1SD2/Jl2BuwP4N3ermVT3dNFV7u4v/+f x6E= ;; Received 441 bytes from 192.168.15.2#53(192.168.15.2) in 351 ms com.172800INNSa.gtld-servers.net. com.172800INNSi.gtld-servers.net. com.172800INNSj.gtld-servers.net. com.172800INNSh.gtld-servers.net. com.172800INNSf.gtld-servers.net. com.172800INNSg.gtld-servers.net. com.172800INNSb.gtld-servers.net. com.172800INNSk.gtld-servers.net. com.172800INNSl.gtld-servers.net. com.172800INNSc.gtld-servers.net. com.172800INNSe.gtld-servers.net. com.172800INNSm.gtld-servers.net. com.172800INNSd.gtld-servers.net. com.86400INNSECcoop. NS RRSIG NSEC com.86400INRRSIGNSEC 8 1 86400 2010062907 2010062206 55138 . HgSWgEehhDAiFJZGH164RXHv+QAE69DFF8QVsIiP+tR3FvSi5aijuv6N a+ED1Wwj77dZYH0RNCrYrMiB1ct1pQ6p5WTFF5WoLXMVRxLPkRxT/UV7 MsQfqvkkaxWRQfRqHAzBbAeaZKAsGL8FGU1kT6e3AozNcY4dQm/ESzGB vzU= ;; Received 725 bytes from 128.8.10.90#53(d.root-servers.net) in 157 ms replacementservices.com. 172800INNSns33.domaincontrol.com. replacementservices.com. 172800INNSns34.domaincontrol.com. ;; Received 136 bytes from 192.12.94.30#53(e.gtld-servers.net) in 53 ms ;; connection timed out; no servers could be reached On 23/06/10 17:49, Erwin Lansing wrote: > On Wed, Jun 23, 2010 at 05:25:31PM +0200, Warren Kumari wrote: > # dig +dnssec @ns33.domaincontrol.com. replacementservices.com. >>> Since it's working quite okay for several locations on here, the >>> problem may be found somewhere in between sites. >>> >>> I personally don't get any failures with the dig statement from above >>> no matter how often I try. >>> >>> >> >> Me neither! Me neither! >> >> >> I also goes through AboveNet. >> >> > A few more datapoints. I tried from 4 different AS numbers, two in > Europe, two in the US, two routed via GLBX and two via above. Only one > of them works (via Above). I'm at a loss at finding similarities > between the non-working ones. > > -erwin > > > > > ___
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
If it is not a local DPI problem then the only other thing is that domaincontrol.com in using anycast and one or more of the sites is using using nameservers that don't respond to EDNS queries or has a firewall that blocks EDNS queries. Mark % traceroute -I ns33.domaincontrol.com traceroute to ns33.domaincontrol.com (216.69.185.17), 64 hops max, 60 byte packets 1 bsdi (192.168.191.233) 6.502 ms 8.335 ms 2.612 ms 2 10.72.0.1 (10.72.0.1) 8.692 ms 8.043 ms 8.030 ms 3 bla2-ge0-1.gw.optusnet.com.au (198.142.160.185) 15.227 ms 11.729 ms 18.273 ms 4 sbr3-ge14-0-0-821.gw.optusnet.com.au (211.29.156.12) 12.359 ms 8.048 ms 12.295 ms 5 203.208.191.73 (203.208.191.73) 176.409 ms 172.225 ms 171.329 ms 6 203.208.182.105 (203.208.182.105) 171.568 ms POS3-2.sngtp-ar2.ix.singtel.com (203.208.182.205) 171.644 ms 203.208.182.105 (203.208.182.105) 174.667 ms 7 ge-4-0-0-0.plapx-cr2.ix.singtel.com (203.208.183.173) 179.206 ms xe-1-0-0-0.plapx-cr2.ix.singtel.com (203.208.183.169) 172.409 ms 174.681 ms 8 ge-3-0-0-0.sngtp-dr1.ix.singtel.com (203.208.183.66) 360.125 ms 360.272 ms so-3-0-3-0.sngtp-cr1.ix.singtel.com (203.208.151.213) 360.054 ms 9 ge-4-0-0-0.sngtp-cr2.ix.singtel.com (203.208.182.102) 349.780 ms ge-1-0-0-0.sngc3-dr1.ix.singtel.com (203.208.173.134) 359.751 ms ae0-0.sngtp-cr2.ix.singtel.com (203.208.183.58) 381.008 ms 10 203.208.131.10 (203.208.131.10) 353.688 ms 378.354 ms ge-3-0-0-0.sngtp-dr1.ix.singtel.com (203.208.183.66) 374.032 ms 11 ge-0-0-0-0.sngc3-dr1.ix.singtel.com (203.208.149.77) 370.884 ms 363.593 ms ip-182-50-156-165.ip.secureserver.net (182.50.156.165) 382.590 ms 12 203.208.131.10 (203.208.131.10) 352.356 ms 355.794 ms ip-182-50-156-154.ip.secureserver.net (182.50.156.154) 370.840 ms 13 ip-182-50-156-150.ip.secureserver.net (182.50.156.150) 372.826 ms 341.247 ms 340.792 ms 14 ns33.domaincontrol.com (216.69.185.17) 342.589 ms 367.762 ms ip-182-50-156-154.ip.secureserver.net (182.50.156.154) 371.792 ms % dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. 72.32.12.235 % % traceroute -I ns33.domaincontrol.com traceroute to ns33.domaincontrol.com (216.69.185.17), 64 hops max, 60 byte packets 1 main.f1.sql1.isc.org (204.152.187.254) 0.288 ms 0.260 ms 0.203 ms 2 core.r1.sql1.isc.org (149.20.48.65) 2.226 ms 2.253 ms 0.966 ms 3 int-0-4-0-0.r1.pao1.isc.org (149.20.65.9) 2.722 ms 1.147 ms 3.836 ms 4 ge-9-15-1G.ar1.PAO2.gblx.net (64.215.195.21) 74.308 ms 74.351 ms 74.134 ms 5 64.209.110.218 (64.209.110.218) 19.212 ms 33.005 ms 71.280 ms 6 ip-208-109-112-153.ip.secureserver.net (208.109.112.153) 19.890 ms 21.273 ms 20.580 ms 7 ip-208-109-112-142.ip.secureserver.net (208.109.112.142) 19.835 ms 25.676 ms 18.667 ms 8 ip-208-109-114-129.ip.secureserver.net (208.109.114.129) 19.844 ms 20.143 ms 20.079 ms 9 ip-97-74-252-18.ip.secureserver.net (97.74.252.18) 20.839 ms 20.461 ms 22.330 ms 10 ns33.domaincontrol.com (216.69.185.17) 21.460 ms 21.474 ms 21.827 ms % dig +short +dnssec @ns33.domaincontrol.com. replacementservices.com. 72.32.12.235 % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((
In article , Mark Andrews wrote: > If it is not a local DPI problem then the only other thing > is that domaincontrol.com in using anycast and one or more > of the sites is using using nameservers that don't respond > to EDNS queries or has a firewall that blocks EDNS queries. A few minutes poking around with traceroute.org finds the same two destinations that Mark does, one apparently in Washington DC or close by accessed via AboveNet, GBLX, Level3 and maybe others, and the other in or around Singapore, accessed via SingTel. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users