Hide Forgot
Description of problem: Unbound is failing dnssec verification for domains like bug12345.bugzilla.mozilla.org Version-Release number of selected component (if applicable): unbound-1.4.16-2.fc17.x86_64 How reproducible: always Steps to Reproduce: 1. Set up (via dnssec-trigger in my case) unbound 2. dig bug12345.bugzilla.mozilla.org @localhost 3. 4. Actual results: SERVFAIL Expected results: works Additional info: from dnssec-tools, the 'validate' cli tool confirms that this is working correctly: $ validate bug12345.bugzilla.mozilla.org Result: ****START**** Result: OK Result: ****END**** 4.209688 sec Using my ISP's resolver: $ dig +dnssec bug12345.bugzilla.mozilla.org ; <<>> DiG 9.9.0-RedHat-9.9.0-4.fc17 <<>> +dnssec bug12345.bugzilla.mozilla.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3803 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;bug12345.bugzilla.mozilla.org. IN A ;; ANSWER SECTION: bug12345.bugzilla.mozilla.org. 60 IN CNAME wildcard.bugzilla.3crowd.mozilla.net. bug12345.bugzilla.mozilla.org. 60 IN RRSIG CNAME 7 3 60 20120621235800 20120523000612 63920 mozilla.org. v4rtH1JIpBgD/p8AuA+brUF9uLjy4t75Gez8kLAwJuccC+tRRuG5IZSt v0zxINcZIjk7oANS7Ql7j9xZDW/IsWhmW4/Aos4LKioJlxWHlcAeAxKh dtaGAMIVZVes3NB2ap2JgPgkBGYqOVJeQP/BhZdKunwGHDOz+0mi8ncp 5pc= wildcard.bugzilla.3crowd.mozilla.net. 30 IN A 63.245.217.61 ;; AUTHORITY SECTION: bugzilla.3crowd.mozilla.net. 2987 IN NS r2.3crowd.com. ;; ADDITIONAL SECTION: r2.3crowd.com. 1515 IN A 173.249.43.30 r2.3crowd.com. 1515 IN A 74.115.30.30 ;; Query time: 164 msec ;; SERVER: 203.2.75.132#53(203.2.75.132) ;; WHEN: Wed May 23 12:34:01 2012 ;; MSG SIZE rcvd: 354
Its also failing in the same way on foo.fedorapeople.org - seems like something is wrong with wildcard DNS records maybe?
Hmm, I just tested this on my own fedora 16, and it works: [paul@bofh pluto]$ dig bug12345.bugzilla.mozilla.org ; <<>> DiG 9.8.2-RedHat-9.8.2-2.fc16 <<>> bug12345.bugzilla.mozilla.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45328 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;bug12345.bugzilla.mozilla.org. IN A ;; ANSWER SECTION: bug12345.bugzilla.mozilla.org. 59 IN CNAME wildcard.bugzilla.3crowd.mozilla.net. wildcard.bugzilla.3crowd.mozilla.net. 30 IN A 63.245.217.61 There is no AD bit because it is a CNAME into mozilla.net which has no DS record. foo.fedoraproject.org works for me as well. on fedora 16. If it is still happening to you, can you show me the output of sudo unbound-control list_forwards and the output of sudo dnssec-trigger-control results If you were on a hotspot, one thing that might be happening is that it was too broken and it fell back to using DNS over TLS to the fedoraproject.org servers. Those connections can time out, and if there are cname/wildcard indirections that might cause more lookups
I got the ServFail failure too on a very difficult hotspot only allowing me dns over tcp. I'm not sure what can be done here. The problem is that bugzilla.mozilla.org points to a CNAME that points to a CNAME that points to a new TLD that points to another CNAME, and unbound has to use TCP for al these queries and validate the cname destinations along the way. bug12345.bugzilla.mozilla.org. CNAME to wildcard.bugzilla.3crowd.mozilla.net. CNAME to bugzilla.mozilla.org. CNAME to bugzilla.3crowd.mozilla.net. CNAME to bugzilla.zlb.phx.mozilla.net. unbound I believe sets up a tcp connection per query, it is not able to chain requests, or receive/generate dnssec-chains. But I would like to confirm that you were actually on a "broken" network and that dnssec-trigger/unbound did cause you to fallback to TCP....
This is F17, FWIW I'm not on a hotspot here - this is a work PC, so its behind a firewall though. (Won't be able to check from home til later) Its not the CNAMEs, because foo.fedorapeople.org doesn't involve CNAMEs and has the same issue $ sudo unbound-control list_forwards . IN forward: 203.2.75.132 198.142.0.51 $ sudo dnssec-trigger-control results at 2012-05-23 15:28:23 cache 198.142.0.51: OK cache 203.2.75.132: OK state: cache secure the last command hangs after that output though, but the help for that option says its a "continuous feed of probe results" so I think its meant to. (Note that I have root access to those caching servers if you need more info from them. /var/log/messages has: May 24 09:31:15 bradley unbound: [1073:0] info: validation failure foo.fedorapeople.org. A IN looking up '*.fedorapeople.org' *does* work though. (BTW, I notice that if I just restart unbound, I need to manually reprobe via the applet before it does dnssec validation tests. That's a separate bug though, it appears) If I turn verbosity up (to 99, via ubound-control. and disable ratelimiting in rsyslog), I get: May 24 09:38:06 bradley rsyslogd-2177: imuxsock lost 273 messages from pid 24502 due to rate-limiting May 24 09:38:06 bradley unbound: [24502:1] info: validator operate: query foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: resolving foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: processQueryTargets: foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: DelegationPoint<.>: 0 names (0 missing), 2 addrs (0 result, 2 avail) cacheNS May 24 09:38:06 bradley unbound: [24502:1] info: sending query: foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: mesh_run: end 1 recursion states (0 with reply, 1 detached), 0 waiting replies, 22 recursion replies sent, 0 replies dropped, 0 states jostled out May 24 09:38:06 bradley unbound: [24502:1] info: average recursion processing time 3.168268 sec May 24 09:38:06 bradley unbound: [24502:1] info: histogram of recursion processing times May 24 09:38:06 bradley unbound: [24502:1] info: [25%]=0.563931 median[50%]=1 [75%]=2.33333 May 24 09:38:06 bradley unbound: [24502:1] info: lower(secs) upper(secs) recursions May 24 09:38:06 bradley unbound: [24502:1] info: 0.002048 0.004096 1 May 24 09:38:06 bradley unbound: [24502:1] info: 0.016384 0.032768 1 May 24 09:38:06 bradley unbound: [24502:1] info: 0.131072 0.262144 2 May 24 09:38:06 bradley unbound: [24502:1] info: 0.262144 0.524288 1 May 24 09:38:06 bradley unbound: [24502:1] info: 0.524288 1.000000 6 May 24 09:38:06 bradley unbound: [24502:1] info: 1.000000 2.000000 5 May 24 09:38:06 bradley unbound: [24502:1] info: 2.000000 4.000000 3 May 24 09:38:06 bradley unbound: [24502:1] info: 16.000000 32.000000 3 May 24 09:38:06 bradley unbound: [24502:1] info: 0RDd mod1 foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: iterator operate: query foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: scrub for . NS IN May 24 09:38:06 bradley unbound: [24502:1] info: response for foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: reply from <.> 203.2.75.132#53 May 24 09:38:06 bradley unbound: [24502:1] info: incoming scrubbed packet: ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 May 24 09:38:06 bradley unbound: [24502:1] info: query response was ANSWER May 24 09:38:06 bradley unbound: [24502:1] info: finishing processing for foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: validator operate: query foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: signer is fedorapeople.org. TYPE0 CLASS0 May 24 09:38:06 bradley unbound: [24502:1] info: validator: FindKey foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: verify rrset foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: verify rrset fedorapeople.org. NS IN May 24 09:38:06 bradley unbound: [24502:1] info: validator: response has failed AUTHORITY rrset: fedorapeople.org. NS IN May 24 09:38:06 bradley unbound: [24502:1] info: validate(positive): sec_status_bogus May 24 09:38:06 bradley unbound: [24502:1] info: resolving foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: processQueryTargets: foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: DelegationPoint<.>: 0 names (0 missing), 2 addrs (0 result, 2 avail) cacheNS May 24 09:38:06 bradley unbound: [24502:1] info: sending query: foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: mesh_run: end 1 recursion states (0 with reply, 1 detached), 0 waiting replies, 22 recursion replies sent, 0 replies dropped, 0 states jostled out May 24 09:38:06 bradley unbound: [24502:1] info: average recursion processing time 3.168268 sec May 24 09:38:06 bradley unbound: [24502:1] info: histogram of recursion processing times May 24 09:38:06 bradley unbound: [24502:1] info: [25%]=0.563931 median[50%]=1 [75%]=2.33333 May 24 09:38:06 bradley unbound: [24502:1] info: lower(secs) upper(secs) recursions May 24 09:38:06 bradley unbound: [24502:1] info: 0.002048 0.004096 1 May 24 09:38:06 bradley unbound: [24502:1] info: 0.016384 0.032768 1 May 24 09:38:06 bradley unbound: [24502:1] info: 0.131072 0.262144 2 May 24 09:38:06 bradley unbound: [24502:1] info: 0.262144 0.524288 1 May 24 09:38:06 bradley unbound: [24502:1] info: 0.524288 1.000000 6 May 24 09:38:06 bradley unbound: [24502:1] info: 1.000000 2.000000 5 May 24 09:38:06 bradley unbound: [24502:1] info: 2.000000 4.000000 3 May 24 09:38:06 bradley unbound: [24502:1] info: 16.000000 32.000000 3 May 24 09:38:06 bradley unbound: [24502:1] info: 0RDd mod1 foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: iterator operate: query foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: scrub for . NS IN May 24 09:38:06 bradley unbound: [24502:1] info: response for foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: reply from <.> 198.142.0.51#53 May 24 09:38:06 bradley unbound: [24502:1] info: incoming scrubbed packet: ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 0 May 24 09:38:06 bradley unbound: [24502:1] info: query response was ANSWER May 24 09:38:06 bradley unbound: [24502:1] info: finishing processing for foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: validator operate: query foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: validator operate: chased to . TYPE0 CLASS0 May 24 09:38:06 bradley unbound: [24502:1] info: signer is fedorapeople.org. TYPE0 CLASS0 May 24 09:38:06 bradley unbound: [24502:1] info: validator: FindKey foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: verify rrset foo.fedorapeople.org. A IN May 24 09:38:06 bradley unbound: [24502:1] info: verify rrset fedorapeople.org. NS IN May 24 09:38:06 bradley unbound: [24502:1] info: validator: response has failed AUTHORITY rrset: fedorapeople.org. NS IN May 24 09:38:06 bradley unbound: [24502:1] info: validate(positive): sec_status_bogus so it can get the data, just not validate it.
BTW, I tested at home, and get the same failures, including when I use 8.8.8.8 as my resolver (for testing)
8.8.8.8 is known to be broken for DS records, so it will properly fail DNSSEC validation for fedoraproject.org. but using dnssec-trigger, it should then ignore your DHCP obtained DNS server and recurse itself.
Are you definitely not seeing issues with dnssec-trigger and looking up foo.fedorapeople.org? I've tried: - 8.8.8.8 - my ISP's nameservers (a bunch of them) - opendns (208.67.222.222 and 208.67.220.220) and with all of them I can lookup fedorapeople.org but get a SERVFAIL from unbound with foo.fedorapeople.org. I flushed the cache (unbound-control flush_zone .) between each try, just in case. everything else works - it just seems to be wildcard lookups that fail, with the same type of log messages (see comment 4) for each one
This is unbound (1.4.16-2.fc17.x86_64) on my laptop configured automatically via dnssec-triggerd (0.10-4.fc17.x86_64) [paul@thinkpad ~]$ dig +dnssec *.fedorahosted.org ; <<>> DiG 9.9.1-RedHat-9.9.1-1.fc17 <<>> +dnssec *.fedorahosted.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35854 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;*.fedorahosted.org. IN A ;; ANSWER SECTION: *.fedorahosted.org. 40 IN CNAME hosted03.fedoraproject.org. *.fedorahosted.org. 40 IN RRSIG CNAME 5 2 60 20120704212813 20120604212813 39900 fedorahosted.org. Pnfwv9jexjdInYtQUD9t7EvVXf3ivjmuKXgLd/u+L1XIQH0FpdXX+r7k p0zKHCJPNocbOMp2C7+ENb+dgSKI/Ik2Qf5OMinSCRQ4n61SObF1YO2R Aq4jtsHnd/M/Kqt2spVmuofxjSJSUpa1C8r4qd8eu57FudUoyyX/8V7T 32E= hosted03.fedoraproject.org. 280 IN A 66.135.62.191 hosted03.fedoraproject.org. 280 IN RRSIG A 5 3 300 20120704212814 20120604212814 7725 fedoraproject.org. EXuvX42bp16Kv5vwSzuRmaaLXL1XEpGcz34diLKgw79vigUIWKXSmWYa JxnDyvgbOk1tTfoY2fqFDBA7HzATNfhJxVArIGHB3Ho34TBfdFKXmMgp 8tZLm7TSDiPUmLDw0asN3pgR6vXf24VR9Rghu8kS6qxQUleaLb3XqGfr Jgk= same for fedorapeople.org: ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;*.fedorapeople.org. IN A ;; ANSWER SECTION: *.fedorapeople.org. 60 IN A 152.19.134.191 *.fedorapeople.org. 60 IN RRSIG A 5 2 60 20120704212734 20120604212734 378 fedorapeople.org. r664r7gCPoa5AphMQKoEi4acuTCu06hIJvz8s/ptdsojg/3n7SOullb/ e1pHf9rzdrx9EhXsccGp6aDBEeQGUs3T/MxZBtot2qM5GF8JCwdZ2z1e Kff35nS9+pdvxZlCWYziSRNwz1m1jlL3vtoJvkMGR0PZrNu6v2C0bxqd qjU= can you should me your "sudo dnssec-trigger-control results" and your "sudo unbound-control list_forwards" ? Note that just flushing "." might not be enough, You might also need to run: sudo unbound-control flush_requestlist
looking up '*.fedorapeople.org' works, but 'foo.fedorapeople.org' doesn't. $ sudo dnssec-trigger-control results at 2012-06-05 09:27:49 cache 198.142.0.51: OK cache 203.2.75.132: OK state: cache secure $ sudo unbound-control list_forwards . IN forward: 203.2.75.132 198.142.0.51 If I change to the opendns ones, I start to get errors from dnssec-trigger-control results (eg 'no RRSIG'). However if I use 8.26.56.26 (comodo dns) then I *can* resolve foo.fedorapeople.org When I dig +dnssec @my DNS server (which is publically available if you want to look for yourself....), the AUTHORITY has: ;; AUTHORITY SECTION: fedorapeople.org. 38419 IN NS ns02.fedoraproject.org. fedorapeople.org. 38419 IN NS ns05.fedoraproject.org. fedorapeople.org. 38419 IN NS ns-sb01.fedoraproject.org. fedorapeople.org. 38419 IN NS ns04.fedoraproject.org. which doesn't include the '*.fedoraproject.org' NSEC/RRSIG records that I get if I dig @8.26.56.26: ;; AUTHORITY SECTION: *.fedorapeople.org. 86400 IN NSEC fedorapeople.org. A AAAA RRSIG NSEC *.fedorapeople.org. 86400 IN RRSIG NSEC 5 2 86400 20120704223654 20120604223654 378 fedorapeople.org. i5mTAJJzMCo+Sbv0uzVwCELIRYQOghX4X0g9Yh2Gch2xWdWN09ANKP+6 wS32zh85+bED8To7gNT7c082GEDFalPGvHdWaWVgwR9pN/kzlwaxJoyE n7ALn+k6QXnrzlk+YKQ/2RGjrGyme8EFpwiOcG4czyD3V7Rl1qV6aL/k JUA= Is this a bind bug (and then also a dnssec-trigger bug, for not finding that)? Or should unbound be asking for this if needed. The DNS servers I'm using don't have any dnssec config options enabled.
I'm not sure if this is a bind bug or not. The RRSIG has an rrsig_label value of 2, so unbound knows it needs to look up '*.fedorapeople.org' to do the resolution. RFC4035 says (section 5.3.4) Note that the response received by the resolver should include all NSEC RRs needed to authenticate the response (see Section 3.1.3). but section 3.1.3 is refering to authoritative servers, and the recusrive DNS server being used isn't dnssec aware anyway.
I can reproduce the missing wildcard/RRSIG for *.fedorapeople.org in the authority. But even with that, using localhost as a resolver, it still fails: 1. Install bind-9.9.0-4.fc17.x86_64 2. sudo ip addr add 1.2.3.4 dev lo - Yes this is a hack.... 3. Change the as-shipped named.conf to: - listen on 1.2.3.4 - comment out the v6 listen - comment out the dnssec-validation and dnssec-lookaside options 4. start/restart named 6. Check that 'dig +dnssec foo.fedorapeople.org @1.2.3.4' doesn't include a wildcard RRSIG in the AUTHORITY section 6. Change network-manager to use 1.2.3.4 as the dns server 7. reprobe dnssec-trigger $ sudo unbound-control list_forwards . IN forward: 127.0.0.2 8. 'host foo.fedorapeople.org' fails 9. Edit named.conf, enable the dnssec-validation/dnssec-lookaside options. 10. restart named, and flush unbound 11. 'dig +dnssec foo.fedorapeople.org @1.2.3.4' does include the RRSIG 12. dig @localhost still fails. Looking at the tcpdump for (12) though, the wildcard RRSIG is not being returned from bind to unbound. I can repro this if I use 'dig +nocdflag', which is what unbound sends. Anyway, steps 1-8 should hopefully let you reproduce this.
Paul asked me to add my results when I ran into this issue. I am getting the following on my system for similar issues: [smooge@seiji Downloads]$ sudo dnssec-trigger-control results Jun 21 14:54:08 dnssec-trigger-control[9227] fatal error: SSL handshake failed error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed [smooge@seiji Downloads]$ sudo unbound-control list_forwards error: SSL handshake failed 140273590888320:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1063: $ rpm -q unbound unbound-1.4.16-2.fc17.x86_64
this looks like a named bug: [root@thinkpad paul]# dig +dnssec foo.fedorapeople.org @1.2.3.4 ; <<>> DiG 9.9.1-RedHat-9.9.1-1.fc17 <<>> +dnssec foo.fedorapeople.org @1.2.3.4 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32579 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 5 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;foo.fedorapeople.org. IN A ;; ANSWER SECTION: foo.fedorapeople.org. 60 IN A 152.19.134.191 foo.fedorapeople.org. 60 IN RRSIG A 5 2 60 20120718155814 20120618155814 378 fedorapeople.org. QSawyRwcNT+MDhuZ8ggeLr3mS1ULVIzQN7nwYzEVLFWbsolSO24kEEpj KmvggCqle7N1kTTAyNd3Rwr6/33/9rj48INxymgGGhwbf1uHsqFRRw4c zz71XF4bahNALpfPwFMCYszaXUOpCmYU8VP7IIHeoOFcbMxedCo2NGbE 3nU= ;; AUTHORITY SECTION: fedorapeople.org. 86180 IN NS ns05.fedoraproject.org. fedorapeople.org. 86180 IN NS ns-sb01.fedoraproject.org. fedorapeople.org. 86180 IN NS ns02.fedoraproject.org. fedorapeople.org. 86180 IN NS ns04.fedoraproject.org. ;; ADDITIONAL SECTION: ns-sb01.fedoraproject.org. 86180 IN A 69.174.247.243 ns05.fedoraproject.org. 86180 IN A 85.236.55.10 ns02.fedoraproject.org. 86180 IN A 152.19.134.139 ns04.fedoraproject.org. 86180 IN A 209.132.181.17
bind 9.8.1 also does not put in the RRSIG for the authority section. This seems normal behaviour? but unbound treats it as a "stripped" answer, and does not ask for the NS RRset and so it never sees the RRSIG
I don't think that this is a bind bug - when bind is not configured to be DNSSIG aware, requiring it to look up and fetch the RRSIG records shouldn't be a requirement.
Bind is configured to dnssec aware (dnssec-enable yes) It is just not configured to perform validation (no dnssec-validation yes)
hmm, even if bind is configured with dnssec validation, and queried directly using dig +dnssec, it gives an answer without the AD bit. So this is clearly a bind bug. re-assigned the bug to bind. note that I reproduced this in bind 9.9.1 as well as 9.8.1.
I'll try and track it. dnssec-trigger might need to get a new probe for this, and reject using such servers as Mark states. From: Mark Andrews <marka> BIND bug, the "NOQNAME" NSEC/NSEC3 proof extraction is a side effect of validation. That said if you are talking through a recursive server that server should be validating as there are situations that are not recoverable without it. Mark
> Bind is configured to dnssec aware (dnssec-enable yes) > It is just not configured to perform validation (no dnssec-validation yes) I see this even when bind is not configured to be dnssec aware. Is it still a bind bug in that case?
This bug has been assigned RT#21409 by ISC
Bradley: if the upstream resolver is not dnssec-aware, it willl not return RRSIGs, so dnssec-trigger will mark is as "unusable"
RT#21409 was fixed in bind 9.9.3b1, so this bug can be closed once 9.9.3 is released and packaged (although it might still break fedora users who are "stuck" behind an older forwarding bind instance.
What about changing dnssec-trigger to test a wildcard address?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
bind-9.9.3-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/bind-9.9.3-1.fc19
bind-dyndb-ldap-2.6-2.fc18,dnsperf-2.0.0.0-4.fc18,dhcp-4.2.5-12.fc18,bind-9.9.3-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/bind-dyndb-ldap-2.6-2.fc18,dnsperf-2.0.0.0-4.fc18,dhcp-4.2.5-12.fc18,bind-9.9.3-2.fc18
dhcp-4.2.5-2.fc17,dnsperf-2.0.0.0-3.fc17,bind-dyndb-ldap-2.5-2.fc17,bind-9.9.3-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dhcp-4.2.5-2.fc17,dnsperf-2.0.0.0-3.fc17,bind-dyndb-ldap-2.5-2.fc17,bind-9.9.3-2.fc17
Package dhcp-4.2.5-2.fc17, dnsperf-2.0.0.0-3.fc17, bind-dyndb-ldap-2.5-2.fc17, bind-9.9.3-3.P1.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dhcp-4.2.5-2.fc17 dnsperf-2.0.0.0-3.fc17 bind-dyndb-ldap-2.5-2.fc17 bind-9.9.3-3.P1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10100/dhcp-4.2.5-2.fc17,dnsperf-2.0.0.0-3.fc17,bind-dyndb-ldap-2.5-2.fc17,bind-9.9.3-3.P1.fc17 then log in and leave karma (feedback).
bind-9.9.3-3.P1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
bind-dyndb-ldap-2.6-2.fc18, dnsperf-2.0.0.0-4.fc18, dhcp-4.2.5-12.fc18, bind-9.9.3-3.P1.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
dhcp-4.2.5-2.fc17, dnsperf-2.0.0.0-3.fc17, bind-dyndb-ldap-2.5-2.fc17, bind-9.9.3-3.P1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
Still not working for me (unbound forwarding to a pair of bind-9.9.3-3.P1 servers). $ dig repos.fedorapeople.org ; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.fc17 <<>> repos.fedorapeople.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9905 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;repos.fedorapeople.org. IN A ;; Query time: 4256 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Qui Jul 11 16:44:41 BRT 2013 ;; MSG SIZE rcvd: 51 unbound[27201]: [27201:1] info: validation failure repos.fedorapeople.org. A IN Packages: unbound-1.4.19-1.fc17.x86_64 dnssec-trigger-0.11-3.fc17.x86_64
(In reply to Bradley from comment #23) > What about changing dnssec-trigger to test a wildcard address? upstream is reluctant to add such a specific test because such a wildcard test is not available at a large TLD. All their tests currently test against TLDs, to reduce the chance of the record changing and to avoid privacy issues.
there are now stable TLD entries to implement this feature in dnssec-trigger: *._probe.uk.com *._probe.us.com *._probe.cn.com Contact for these entries is Gavin Brown at CentralNIC
re-opening as the bug is not so much bind, but the fact that unbound/dnssec-trigger forwards to a broken old bind without realising it is broken
*** Bug 1108330 has been marked as a duplicate of this bug. ***
Thanks, Paul
(In reply to Paul Wouters from comment #35) > re-opening as the bug is not so much bind, but the fact that > unbound/dnssec-trigger forwards to a broken old bind without realising it is > broken Removing the fixed in version field.
So how do we handle the detection of bad bind installation in dnssec-trigger? For now we at least need to know that those local resolvers are broken and that we shouldn't use them. How exactly should the detection code be improved?
I did some experiments with Unbound (running on localhost and is using broken forwarder). In my case dnssec-trigger thinks that forwarder is okay but it is not. $ dig +dnssec @127.0.0.1 www.manikova-pizza.cz gives me SERVFAIL and journal says "validation failure". For some reason dig +dnssec @127.0.0.1 test._probe.uk.com. works, I don't know why. Maybe the difference is that wildcard *.manikova-pizza.cz contains A record but *._probe.uk.com contains CNAME. I don't know. Paul, do you have any ideas?
can you run both digs with +cd so we can see the records returned? From what I remember, the broken bind will omit one of the NSEC(3) records for proof and unbound cannot prove the non-existence of the non-wildcard entry. Probing seems to be done in the probe.c file, but it seems that this process is not very structured (or I dont understand it fully). I would suggest sending a question about adding a probe to the dnssec-trigger mailing list.
(In reply to Paul Wouters from comment #41) > can you run both digs with +cd so we can see the records returned? > > From what I remember, the broken bind will omit one of the NSEC(3) records > for proof and unbound cannot prove the non-existence of the non-wildcard > entry. Correct results: $ dig +dnssec www.manikova-pizza.cz ; <<>> DiG 9.9.5-P1-RedHat-9.9.5-8.P1pspacekO0.fc21 <<>> +dnssec www.manikova-pizza.cz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9507 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.manikova-pizza.cz. IN A ;; ANSWER SECTION: www.manikova-pizza.cz. 86400 IN A 193.19.176.166 www.manikova-pizza.cz. 86400 IN RRSIG A 5 2 86400 20140908041020 20140809041020 41688 manikova-pizza.cz. dzvlS/PHcQ2ZyksRYVMoZmS6VFZMrhmrqeNp2IJ+HBz89laemMbT9Jyz 5NQQBrNkVqfsDzwZvgFadCmbzCerTrdgvhTDB2Zu1osv5Z7VkCVmVYh3 HKDriECWmXoQZss3H3jtzmP5XDOhH7r0V39aE2mjmBitlsA7Xgv+MqVA jec= ;; AUTHORITY SECTION: *.manikova-pizza.cz. 86400 IN NSEC manikova-pizza.cz. A RRSIG NSEC *.manikova-pizza.cz. 86400 IN RRSIG NSEC 5 2 86400 20140908041020 20140809041020 41688 manikova-pizza.cz. o3XvCQg3BDPh+xCoE5Jlo5TUBDgqnPShISV5EPtH6P5vWjdVUJ/p2OQb TuVAXIbnOVKI/c4NSC4/8G2rgo+lNVV2N8wMRpjs4k2hgR3j0TlB5a/6 K8HbyOC+6aPNn6yfr0uIDgE83hZJ6DDXh5oGWdKVXcpvgYNtugCWV2N0 dcE= manikova-pizza.cz. 3600 IN NS alfa.ns.active24.cz. manikova-pizza.cz. 3600 IN NS beta.ns.active24.cz. manikova-pizza.cz. 3600 IN NS gama.ns.active24.sk. manikova-pizza.cz. 3600 IN RRSIG NS 5 2 3600 20140908041020 20140809041020 41688 manikova-pizza.cz. Zs4bhnZdjRc1w2GkWLEDblEP3qyfR5pX/hEM4atM7XX78bg6a1858qGa OOanHYUMofkeSc28zwFkyb6wxARPPQ2NO67TZeiTAYbtleS3UhCxHmZK +OpLSOXzHibINMozM5Ouozto24RillkV1dZYUHrn85k4bbl85gCkGf2/ MB8= ;; Query time: 32 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Aug 15 17:27:34 CEST 2014 ;; MSG SIZE rcvd: 721 And this is response which didn't validate: dig +cd +dnssec www.manikova-pizza.cz ; <<>> DiG 9.9.4-P2-RedHat-9.9.4-15.P2.fc20 <<>> +cd +dnssec www.manikova-pizza.cz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17450 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 14 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.manikova-pizza.cz. IN A ;; ANSWER SECTION: www.manikova-pizza.cz. 63659 IN A 193.19.176.166 www.manikova-pizza.cz. 63659 IN RRSIG A 5 2 86400 20140909054822 20140810054822 41688 manikova-pizza.cz. GU+oKFlte4rEUHuMTus5YSUr8AejVJVkuMNYAS9R5BZNCYJKjg2Apnw/ TgvhvGfW7lWGnZ5NnhKKaigtPU2L7czpbueZVPT1GvrF43n8lV3DzEGR HFtTso/rzbJMLKyBqzbwYJ5nMKMMedYdUx3vnwdgdSuE00rHS64/E4Sw nCI= ;; AUTHORITY SECTION: *.manikova-pizza.cz. 63659 IN NSEC manikova-pizza.cz. A RRSIG NSEC *.manikova-pizza.cz. 63659 IN RRSIG NSEC 5 2 86400 20140909054822 20140810054822 41688 manikova-pizza.cz. myVjc09K9cjz582eVt2n+fuplxe2Eqv7cX2F0ahaJjKtRW9sLwnCvG+r 5ABssK5puBSt8m5aHiuLVKEi3CmLLgwHMBzAvCNVd5IIiNUUIQU5c6ry 2yZNg+BPyc/slNTJnOgScvDoyoKW14TISkIq4nT0ORCXf17ncG3q3gWI P3A= cz. 86395 IN NS a.ns.nic.cz. cz. 86395 IN NS b.ns.nic.cz. cz. 86395 IN NS c.ns.nic.cz. cz. 86395 IN NS d.ns.nic.cz. ;; ADDITIONAL SECTION: a.ns.nic.cz. 72974 IN A 194.0.12.1 a.ns.nic.cz. 29105 IN AAAA 2001:678:f::1 b.ns.nic.cz. 153877 IN A 194.0.13.1 b.ns.nic.cz. 29105 IN AAAA 2001:678:10::1 c.ns.nic.cz. 29109 IN A 194.0.14.1 c.ns.nic.cz. 29109 IN AAAA 2001:678:11::1 d.ns.nic.cz. 153877 IN A 193.29.206.1 d.ns.nic.cz. 29109 IN AAAA 2001:678:1::1 a.ns.nic.cz. 96 IN RRSIG A 5 4 1800 20140824173300 20140811122737 47160 nic.cz. sw2rISP5E1es7BjhQ6TqE9K+iVaT4jqhYxxGEniMzO0DdKTIRqLNSw4x 3LZe3G9FOnQH1sNGkf5XipNrXA/KdFrKlcgajaQXlzn3aDdiTL1Hv4cR XsQI047Y/s08i3vsf+8unIBo49NEZDXW6Tp2OExlMR57VlIMQB1L+psw Ll0= a.ns.nic.cz. 114 IN RRSIG AAAA 5 4 1800 20140825061328 20140811122737 47160 nic.cz. hSu5gjoQg619Wj7lZqacPwFwYt2KV4W7t3EFiCZ9SSHrZD0Zb9pSvba5 3YN3PIghz7qSl9oe3+7m7ICP9URiMZKWn7KII3TCTVA9N/Vo87aWXwyu 4Tw6OmDXDEhQKf9EPtCqCEgerc34k3Sd7SobQpQwm072pu/TG/umiQyQ VlY= b.ns.nic.cz. 110 IN RRSIG A 5 4 1800 20140824165059 20140811122737 47160 nic.cz. Q7+12ivEAf5ko2cighQLpb6ON6vOc+suIhvAQQsjzf0IUjItHCVPGIJX 4Eto2bFLz1mjCxN5moxZTdwZie18XwEcKW/pvzSOnQCQ26Ph25Df6/rs lq+FY28Q9XDsJ1gssz+lvKU7dkGZnSEPzuj0fGrJWuZR2n8fQIXuiKdo i0E= b.ns.nic.cz. 110 IN RRSIG AAAA 5 4 1800 20140824182404 20140811122737 47160 nic.cz. VZeCKsDt11zbVLDhRkm0bdm+wGt1dEnKJZDqdOXASbUgVhkyymCPamQl wkuZjJzmai7IpjB3JjQLLyEt63OFpn72XKEQzxt4ni2x1uqObpeWipqi id5KbMU6GDXtjx5Il1Ye16h1jydozj6yN3Bgx8sqKuK1+SLqdImbl8Y2 UsM= d.ns.nic.cz. 117 IN RRSIG AAAA 5 4 1800 20140825020411 20140811122737 47160 nic.cz. MfHcDPCfmTQO8ZvPMimP3OjMsTwh2PdEO+x/XLNFpnXt3aYW9XBSoIv0 qF0zNrEVCn8GzwpZ8HD5vOUv/UJnA5OPdFlFO6r7CrnBq8F+4drRflLI x/nLfrVeWz6NQ32lcFd3Q3sLBRc4ZOnDYpSn4C5tlTtEbTkhMnjHJHy/ uAQ= ;; Query time: 7 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Aug 15 17:32:13 CEST 2014 ;; MSG SIZE rcvd: 1538 It seems that AUTHORITY section is messed up. For some reason it thinks that 'cz' is authoritative ...
Ok, so do we have a specific algorithm to perform the test or a specific set of changes to be commited to dnssec-trigger?
*** Bug 1096240 has been marked as a duplicate of this bug. ***
From duplicate bug report: (Paul Wouters) we now have some records we can use to test for this scenario in dnssec-trigger *._probe.us.com IN CNAME fedoraproject.org. *._probe.uk.com IN CNAME fedoraproject.org. *._probe.kr.com IN CNAME fedoraproject.org. *._probe.uk.net IN CNAME fedoraproject.org. Next is to extend the dnssec-triggerd dnssec tests to test for this bug
Created attachment 957505 [details] patch to use the new data Sorry for not getting to this earlier. So far I just replaced the probe domains with the ones suggested in bugzilla. I have only tested it in a scenario that worked before, so it doesn't seem to break things for me. But... 1) dnssec-trigger (with verbosity 4) won't print out the full answers like it apparently does for other probes. 2) I don't know whether the probe would correctly fail in a bad network. The basic idea is to do wildcard NSEC3 probes *instead* of the regular NSEC3 ones (with the assumption servers that fail non-wildcard is a subset of servers that fail wildcard, correct me if I'm wrong). We'll have to improve the debugging to actually see what's happening. Results of the probes from a bad server would be helpful, though.
(In reply to Petr Spacek from comment #42) > Correct results: > $ dig +dnssec www.manikova-pizza.cz > > *.manikova-pizza.cz. 86400 IN NSEC manikova-pizza.cz. A RRSIG NSEC That sounds like we also need to care about NSEC, right?
(In reply to Pavel Šimerda (pavlix) from comment #46) > Created attachment 957505 [details] > patch to use the new data > > Sorry for not getting to this earlier. So far I just replaced the probe > domains with the ones suggested in bugzilla. I have only tested it in a > scenario that worked before, so it doesn't seem to break things for me. > > But... > > 1) dnssec-trigger (with verbosity 4) won't print out the full answers like > it apparently does for other probes. > > 2) I don't know whether the probe would correctly fail in a bad network. > > The basic idea is to do wildcard NSEC3 probes *instead* of the regular NSEC3 > ones (with the assumption servers that fail non-wildcard is a subset of > servers that fail wildcard, correct me if I'm wrong). We'll have to improve > the debugging to actually see what's happening. I'm not sure we can make this assumption. There might be something really wrong with the server. I think we can just improve the situation by checking for both, regular NSEC3 and wildcard ones.
(In reply to Tomas Hozza from comment #48) > I'm not sure we can make this assumption. There might be something really > wrong with the server. I think we can just improve the situation by checking > for both, regular NSEC3 and wildcard ones. Sent an e-mail[1] to dnssec-trigger mailing list and the authors of the DNSSEC Roadblock Avoidance draft[2]. [1] https://open.nlnetlabs.nl/pipermail/dnssec-trigger/2014-November/000376.html [2] http://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-01
I'm not sure but it would be better to be safe and test both.
(In reply to Petr Spacek from comment #50) > I'm not sure but it would be better to be safe and test both. Btw current upstream switched to testing just wildcard ones (patch by myself), which is already an improvement. It would be good to get the draft updated to give specific recommendations and then implement them.
I'm also affected. My setup is: F21 client $ rpm -q dnssec-trigger unbound dnssec-trigger-0.12-15.fc21.x86_64 unbound-1.5.1-2.fc21.x86_64 CentOS 6.6 LAN DNS server: # rpm -q bind bind-9.8.2-0.30.rc1.el6_6.1.x86_64 # grep dnssec /etc/named.conf dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; $ dig +dnssec @172.16.20.253 patches.fedorapeople.org ; <<>> DiG 9.9.6-RedHat-9.9.6-4.fc21 <<>> +dnssec @172.16.20.253 patches.fedorapeople.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44647 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;patches.fedorapeople.org. IN A ;; ANSWER SECTION: patches.fedorapeople.org. 60 IN A 152.19.134.191 patches.fedorapeople.org. 60 IN RRSIG A 5 2 60 20150117182908 20141218182908 378 fedorapeople.org. lB215gqLkgIksclkRTq9oxFAPEOGokCAVKaGAZDIZrR9gr7QD+BvczYR xA+wwGseImu/lkbOCTfSiQNn/iFEd8CY7sIJaWAkDyXI5s4awwaA9S9q A+iRpdoaxwJPRJL5vD6rKj20g3rTFVL47a6LR+5cDK95SMEicg/Q/Pi2 9dQ= ;; AUTHORITY SECTION: *.fedorapeople.org. 60 IN NSEC fedorapeople.org. A AAAA RRSIG NSEC *.fedorapeople.org. 60 IN RRSIG NSEC 5 2 86400 20150117182908 20141218182908 378 fedorapeople.org. SjMJvsuXeRUQEJAXUPN7jrE5CfazDDAB75INbXCME4JbyDOgaBya1AUX Ct8f5UkCP+6jCSeETteEt7IRcXpklS80E9OoFg3UQrTo/HrBijaqevHH Yauou7cZpOChHhIf3PX44LNYAbHGRlTTd4UF5wbclRT5OrmmKuoXQJ3v adE= ;; Query time: 82 msec ;; SERVER: 172.16.20.253#53(172.16.20.253) ;; WHEN: Mon Dec 22 02:33:27 CET 2014 ;; MSG SIZE rcvd: 461 $ dig +dnssec @localhost patches.fedorapeople.org ; <<>> DiG 9.9.6-RedHat-9.9.6-4.fc21 <<>> +dnssec @localhost patches.fedorapeople.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 32249 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;patches.fedorapeople.org. IN A ;; Query time: 703 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Mon Dec 22 02:33:32 CET 2014 ;; MSG SIZE rcvd: 53
Fixed in rawhide, moving to F21.
dnssec-trigger-0.12-18.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/dnssec-trigger-0.12-18.fc21
Package dnssec-trigger-0.12-18.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dnssec-trigger-0.12-18.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1279/dnssec-trigger-0.12-18.fc21 then log in and leave karma (feedback).
dnssec-trigger-0.12-19.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/FEDORA-2015-3864/dnssec-trigger-0.12-19.fc22
dnssec-trigger-0.12-19.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/FEDORA-2015-3843/dnssec-trigger-0.12-19.fc21
dnssec-trigger-0.12-19.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
dnssec-trigger-0.12-20.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
I'm experiencing a wildcard related issue now and I'm not passing http://0skar.cz/dns/ for wildcard capable DNSSEC resolver. I was told by Ondřej Caletka (the site owner) that he's using randomized subdomains for the test to achieve reliable results. Otherwise there the problem may not be detected due to caching in the forwarder. I have no more details for now.
We indeed need to be very careful about the checks. The following script works for my current home network. It makes wildcard subdomains visible via the local unbound instance even if they would be otherwise made invisible by the first query for a time probably defined by some TTL. So the situation is as follow... 1) The symptom of he problem is that if you first run query through the local Unbound instance (e.g. using dig), you will get SERVFAIL for the query and any subsequent queries for the domain an unspecified time. Running the following script after the first query doesn't help. 2) If you first run the script below, you will get correct data for the domain. Any subsequent queries for the same domain will succeed for an unspecified time. Note: This happens in a specific environment. I have Unbound running on the local host, dnsmasq 2.71 running on the local router using OpenWRT 14.07 and behind it there are ISP's bind servers with the following versions reported through dig. Those are the bad servers but the script works just as well when used on the dnsmasq server, you just can't do it using the local Unbound server. At least that's what my tests showed. "9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.6" "9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.2" #!/bin/bash -x # You need to put a space separated list of bad servers to # be fixed in the $bad_servers variable. # bad_servers="10.111.1.2 109.205.75.156" # # bad_servers="192.168.1.1" # # Or the list of servers could be retrieved using # unbound-control. bad_servers="`unbound-control forward`" # You need to put a domain with wildcard subdomains in the # $domain variable. domain="wilda.nsec.0skar.cz" # You can supply the subdomain on the command line, otherwise # it will be generated using pwgen. if [ "$1" ]; then subdomain="$1" else subdomain="`pwgen`" fi # Keep error output together with data output so you can pipe # it easily to wgetpaste for example. exec 2>&1 # Perform magic on the bad servers. for server in $bad_servers; do # One must not run any the following commands before talking # to the bad server, otherwise the magic won't work! # # dig +short $domain # dig +short $domain @$server dig +short +dnssec $subdomain.$domain @$server done # Check the domain using locally configured resolver. dig +short $subdomain.$domain
Note: I also experienced problems accessing a non-wildcard subdomain where wildcard was also present.
According to tcpdump output for both of the queries, the difference between unbound's query and the magic query (using dig +dnssec) is in the presence or absence of the CD flag. Apparently the upstream nameservers get confused when the first query contains the CD flag and get magically fixed when it doesn't.
This is not specific to F21, reopening.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Created attachment 1131570 [details] patch: use randomized subdomains
Created attachment 1131575 [details] patch: use randomized subdomains
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.