Will unbound ever support a 'server' statement as in bind's
server 1.2.3.4 {
edns no;
};
It seems (probably all) NSxx.DOMAINCONTROL.COM servers (godaddy) don't respond to dnssec queries so I'd like to override my recursive servers never to ask with EDNS.
Hi Rok,
That feature would be blocked under creeping featurism and a desire to
keep unbound light and simple.
Also, dig @ns01.domaincontrol.com. www.godaddy.com +dnssec +norec works
fine, and configuration is not necessary.
Those servers do not include an EDNS OPT section in the answers, which
is not terribly important and unbound 'accepts lenient'.
Best regards,
Wouter
Based on what was said here:
http://brussels38.icann.org/bitcache/e758b09ba8002f798c8fad8f17601e9c8fe5f5ca?vid=13129&disposition=attachment&op=download
We can expect godaddy to fix their servers soon thus you would not
need this option 
Olafur
It seems the problem isn't at godaddy but rather somewhere in between, as bind list users said a couple of times, some of them get the reply using
dig +dnssec @ns33.domaincontrol.com. replacementservices.com.
The only workaround for now seems to be
forward-zone:
name: "replacementservices.com"
forward-addr: 8.8.8.8
forward-addr: 8.8.4.4
....
but doing this on our scale is quite a workout as the servers provide recursive replies for about 200k clients.
Hi Rok,
For me, that command also returns replies. It could be that due to an
anycasted deployment your queries to godaddy end up somewhere else and
somehow this drops queries with EDNS (a firewall?). Could it be your
own firewall? Or some firewall close to you?
unbound detects servers for which EDNS queries are dropped. It takes
time before it kicks in (because a timeout simply takes time to detect,
and more reasons in the doc/requirements.txt). It works by IP-address,
so once ns33 is detected as such, all queries to it are sent without
EDNS, it is cached for infra-ttl seconds (configurable).
Best regards,
Wouter
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.
I have servers at the following providers: AS2107 AS5603 AS34779.
Oh yeah, according to some people routing traffic via other ISPs, like AS3212 and AS8591 everything seems to work, even dnssec queries to godaddy.
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 (204.245.39.50) 54.424 ms 53.878 ms 54.181 ms
14 ip-208-109-115-201.ip.secureserver.net (208.109.115.201) 53.703 ms 54.273 ms 54.446 ms
15 * * *
16 ip-208-109-115-194.ip.secureserver.net (208.109.115.194) 54.772 ms 54.914 ms 55.659 ms
17 ip-208-109-115-113.ip.secureserver.net (208.109.115.113) 54.660 ms 56.149 ms 55.575 ms
18 ip-208-109-115-218.ip.secureserver.net (208.109.115.218) 54.939 ms 55.440 ms 55.163 ms
19 ip-208-109-115-217.ip.secureserver.net (208.109.115.217) 55.841 ms 54.815 ms 53.652 ms
20 ip-208-109-113-62.ip.secureserver.net (208.109.113.62) 53.969 ms 53.489 ms 53.763 ms
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
* Rok Potočnik:
I have servers at the following providers: AS2107 AS5603 AS34779.
Perhaps it's a government-mandated filter which happens not to be
EDNS0-aware?
The traceroutes don't look too bad, except that on the networks I've
got access to, there are not as many hops inside Godaddy's network.
Just to clarify, you get an answer using
dig +norecurse @ns33.domaincontrol.com. replacementservices.com.
but not using
dig +norecurse +dnssec @ns33.domaincontrol.com. replacementservices.com.
?
Hi,
ISP 1# traceroute ns33.domaincontrol.com
Have you tried ?:
$ traceroute --back ns33.domaincontrol.com (might show you asymetric routing, which it probably will, as I've seen it at several hops)
$ dig +dnssec +norec @ns33.domaincontrol.com replacementservices.com. a
$ dig +dnssec +tcp +norec @ns33.domaincontrol.com replacementservices.com. a
$ traceroute -T -p 53 ns33.domaincontrol.com
$ mtr ns33.domaincontrol.com
Maybe it will tell you more of what is going on.
But don't expect miracles.