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.50
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: our isp not supports EDNS?
Mark,
please see below...
On 04.05.2010 / 14:31:25 +1000, Mark Andrews wrote:
In message y2sf7e964441005031927m7774769ev280156817d8b4...@mail.gmail.com,
Je
ff Pang writes:
Hello,
Following the discussions in the list, I made a test on one of our
servers, which is in an ISP's datacenter.
The result is below:
$ dig +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
218.204.255.72 DNS reply size limit is at least 490
218.204.255.72 lacks EDNS, defaults to 512
Tested at 2010-05-04 02:23:51 UTC
Does this mean our ISP's filrewall block EDNS query/response?
Maybe / maybe not. It could just mean that the nameserver itself
doesn't support EDNS.
How bad it is, if providers server doesn't support/make eDNS queries?
Does eDNS support/usage is for DNSSEC protocol only? I mean, that my
collegue propose to use the following statement in named.conf:
server 0.0.0.0/0 {
edns no;
};
in fix to the broken servers, which are doesn't support eDNS queries, for
example ns51 / ns52.domaincontrol.com ( which are hosting a lot of domains
http://www.statsinfinity.com/ns_parent_zone_info/DOMAINCONTROL.COM and dig
+bufsize requests to them are ending with a timeout, so it probably just
firewall'ed for packets more than 512 bytes long).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: our isp not supports EDNS?
Thanks Bill.
I'm well aware of dns-oarc tests...
but they are no more than firewall / dns packet size tests.
My idea/concern is what could be wrong/broken (except of DNSSEC), if we
disable eDNS on our servers - I need to carry this idea to my collegue.
My quick test show that disabling edns per 0/0 { edns no;}; doesn't
broke resolving/anything (except of dnssec queries).
On 22.06.2010 / 10:14:36 -0700, Bill Buhlman wrote:
another example:
dig +short rs.dns-oarc.net txt
rst.x3827.rs.dns-oarc.net.
rst.x3837.x3827.rs.dns-oarc.net.
rst.x3843.x3837.x3827.rs.dns-oarc.net.
Tested at 2010-06-22 17:11:44 UTC
169.199.1.1 sent EDNS buffer size 4096
169.199.1.1 DNS reply size limit is at least 3843
--- On Tue, 6/22/10, Anatoly Pugachev ma...@team.co.ru wrote:
From: Anatoly Pugachev ma...@team.co.ru
Subject: Re: our isp not supports EDNS?
To: Mark Andrews ma...@isc.org
Cc: Jeff Pang pa...@arcor.de, bind-us...@isc.org
Date: Tuesday, June 22, 2010, 8:58 AM
Mark,
please see below...
On 04.05.2010 / 14:31:25 +1000, Mark Andrews wrote:
In message
y2sf7e964441005031927m7774769ev280156817d8b4...@mail.gmail.com, Je
ff Pang writes:
Hello,
Following the discussions in the list, I made a test on one of our
servers, which is in an ISP's datacenter.
The result is below:
$ dig +short rs.dns-oarc.net txt
rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
218.204.255.72 DNS reply size limit is at least 490
218.204.255.72 lacks EDNS, defaults to 512
Tested at 2010-05-04 02:23:51 UTC
Does this mean our ISP's filrewall block EDNS query/response?
Maybe / maybe not. It could just mean that the nameserver itself
doesn't support EDNS.
How bad it is, if providers server doesn't support/make eDNS queries?
Does eDNS support/usage is for DNSSEC protocol only? I mean, that my
collegue propose to use the following statement in named.conf:
server 0.0.0.0/0 {
edns no;
};
in fix to the broken servers, which are doesn't support eDNS queries, for
example ns51 / ns52.domaincontrol.com ( which are hosting a lot of domains
http://www.statsinfinity.com/ns_parent_zone_info/DOMAINCONTROL.COM and dig
+bufsize requests to them are ending with a timeout, so it probably just
firewall'ed for packets more than 512 bytes long).
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
