Bug 824219 - dnssec: unbound fails to validate wildcard records when dnssec-trigger uses a broken bind as forwarder
Summary: dnssec: unbound fails to validate wildcard records when dnssec-trigger uses a...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dnssec-trigger
Version: 28
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Tomáš Hozza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1096240 1108330 (view as bug list)
Depends On:
Blocks: dnssec
TreeView+ depends on / blocked
 
Reported: 2012-05-23 02:34 UTC by Bradley
Modified: 2019-05-28 19:37 UTC (History)
10 users (show)

Fixed In Version: dnssec-trigger-0.12-20.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 19:37:11 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
patch to use the new data (424 bytes, patch)
2014-11-14 10:35 UTC, Pavel Šimerda (pavlix)
no flags Details | Diff
patch: use randomized subdomains (1.68 KB, patch)
2016-02-29 14:46 UTC, Pavel Šimerda (pavlix)
no flags Details | Diff
patch: use randomized subdomains (1.68 KB, patch)
2016-02-29 15:07 UTC, Pavel Šimerda (pavlix)
no flags Details | Diff

Description Bradley 2012-05-23 02:34:24 UTC
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

Comment 1 Bradley 2012-05-23 04:00:12 UTC
Its also failing in the same way on foo.fedorapeople.org - seems like something is wrong with wildcard DNS records maybe?

Comment 2 Paul Wouters 2012-05-23 16:41:05 UTC
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

Comment 3 Paul Wouters 2012-05-23 18:38:20 UTC
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....

Comment 4 Bradley 2012-05-24 00:00:05 UTC
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.

Comment 5 Bradley 2012-05-29 00:43:08 UTC
BTW, I tested at home, and get the same failures, including when I use 8.8.8.8 as my resolver (for testing)

Comment 6 Paul Wouters 2012-05-29 17:32:13 UTC
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.

Comment 7 Bradley 2012-05-30 01:34:37 UTC
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

Comment 8 Paul Wouters 2012-06-04 22:38:47 UTC
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

Comment 9 Bradley 2012-06-05 00:00:00 UTC
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.

Comment 10 Bradley 2012-06-05 00:11:58 UTC
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.

Comment 11 Bradley 2012-06-05 01:24:55 UTC
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.

Comment 12 Stephen John Smoogen 2012-06-21 20:56:57 UTC
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

Comment 13 Paul Wouters 2012-06-23 01:28:52 UTC
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

Comment 14 Paul Wouters 2012-06-23 02:51:40 UTC
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

Comment 15 Bradley 2012-07-08 04:44:52 UTC
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.

Comment 16 Paul Wouters 2012-07-08 19:39:03 UTC
Bind is configured to dnssec aware (dnssec-enable yes)
It is just not configured to perform validation (no dnssec-validation yes)

Comment 17 Paul Wouters 2012-07-09 20:04:55 UTC
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.

Comment 18 Paul Wouters 2012-07-09 23:58:39 UTC
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

Comment 19 Bradley 2012-07-10 00:18:30 UTC
> 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?

Comment 20 Paul Wouters 2012-07-10 15:48:09 UTC
This bug has been assigned RT#21409 by ISC

Comment 21 Paul Wouters 2012-07-10 15:51:18 UTC
Bradley: if the upstream resolver is not dnssec-aware, it willl not return RRSIGs, so dnssec-trigger will mark is as "unusable"

Comment 22 Paul Wouters 2013-03-21 01:02:01 UTC
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.

Comment 23 Bradley 2013-03-23 10:30:25 UTC
What about changing dnssec-trigger to test a wildcard address?

Comment 24 Fedora Admin XMLRPC Client 2013-04-25 11:37:35 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 25 Fedora Update System 2013-06-03 13:26:59 UTC
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

Comment 26 Fedora Update System 2013-06-03 19:48:20 UTC
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

Comment 27 Fedora Update System 2013-06-03 19:52:02 UTC
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

Comment 28 Fedora Update System 2013-06-06 01:28:39 UTC
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).

Comment 29 Fedora Update System 2013-06-13 06:48:57 UTC
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.

Comment 30 Fedora Update System 2013-06-18 01:28:46 UTC
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.

Comment 31 Fedora Update System 2013-06-18 01:36:16 UTC
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.

Comment 32 Cesar Eduardo Barros 2013-07-11 19:53:45 UTC
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

Comment 33 Paul Wouters 2013-07-11 20:18:52 UTC
(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.

Comment 34 Paul Wouters 2014-06-11 19:54:20 UTC
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

Comment 35 Paul Wouters 2014-06-11 19:56:35 UTC
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

Comment 36 Paul Wouters 2014-06-11 19:57:56 UTC
*** Bug 1108330 has been marked as a duplicate of this bug. ***

Comment 37 Pavel Šimerda (pavlix) 2014-06-11 20:17:01 UTC
Thanks, Paul

Comment 38 Pavel Šimerda (pavlix) 2014-06-19 07:35:15 UTC
(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.

Comment 39 Pavel Šimerda (pavlix) 2014-08-14 16:37:25 UTC
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?

Comment 40 Petr Spacek 2014-08-15 09:17:31 UTC
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?

Comment 41 Paul Wouters 2014-08-15 14:54:22 UTC
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.

Comment 42 Petr Spacek 2014-08-15 15:37:55 UTC
(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 ...

Comment 43 Pavel Šimerda (pavlix) 2014-09-23 08:48:22 UTC
Ok, so do we have a specific algorithm to perform the test or a specific set of changes to be commited to dnssec-trigger?

Comment 44 Pavel Šimerda (pavlix) 2014-10-30 15:06:30 UTC
*** Bug 1096240 has been marked as a duplicate of this bug. ***

Comment 45 Pavel Šimerda (pavlix) 2014-10-30 15:07:50 UTC
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

Comment 46 Pavel Šimerda (pavlix) 2014-11-14 10:35:29 UTC
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.

Comment 47 Pavel Šimerda (pavlix) 2014-11-14 10:39:24 UTC
(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?

Comment 48 Tomáš Hozza 2014-11-14 11:31:25 UTC
(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.

Comment 49 Pavel Šimerda (pavlix) 2014-11-14 17:28:40 UTC
(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

Comment 50 Petr Spacek 2014-11-24 13:59:56 UTC
I'm not sure but it would be better to be safe and test both.

Comment 51 Pavel Šimerda (pavlix) 2014-11-24 14:30:59 UTC
(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.

Comment 52 Dominik 'Rathann' Mierzejewski 2014-12-22 01:47:27 UTC
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

Comment 53 Pavel Šimerda (pavlix) 2015-01-20 10:13:11 UTC
Fixed in rawhide, moving to F21.

Comment 54 Fedora Update System 2015-01-26 20:47:35 UTC
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

Comment 55 Fedora Update System 2015-01-28 19:55:58 UTC
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).

Comment 56 Fedora Update System 2015-03-17 11:07:06 UTC
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

Comment 57 Fedora Update System 2015-03-17 11:07:23 UTC
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

Comment 58 Fedora Update System 2015-03-26 22:04:34 UTC
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.

Comment 59 Fedora Update System 2015-04-21 18:49:10 UTC
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.

Comment 60 Pavel Šimerda (pavlix) 2016-01-23 19:28:45 UTC
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.

Comment 61 Pavel Šimerda (pavlix) 2016-01-23 23:21:03 UTC
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

Comment 62 Pavel Šimerda (pavlix) 2016-01-23 23:24:18 UTC
Note: I also experienced problems accessing a non-wildcard subdomain where wildcard was also present.

Comment 63 Pavel Šimerda (pavlix) 2016-01-23 23:39:21 UTC
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.

Comment 64 Petr Spacek 2016-01-26 09:59:59 UTC
This is not specific to F21, reopening.

Comment 65 Jan Kurik 2016-02-24 15:30:12 UTC
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

Comment 66 Pavel Šimerda (pavlix) 2016-02-29 14:46:05 UTC
Created attachment 1131570 [details]
patch: use randomized subdomains

Comment 67 Pavel Šimerda (pavlix) 2016-02-29 15:07:08 UTC
Created attachment 1131575 [details]
patch: use randomized subdomains

Comment 68 Jan Kurik 2016-07-26 04:56:39 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 69 Fedora End Of Life 2017-11-16 19:38:42 UTC
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.

Comment 70 Fedora End Of Life 2017-12-12 10:28:23 UTC
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.

Comment 71 Fedora End Of Life 2018-02-20 15:32:34 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 72 Ben Cotton 2019-05-02 22:04:01 UTC
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.

Comment 73 Ben Cotton 2019-05-28 19:37:11 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.