Bug 447950

Summary: DNSSEC trusted-key {} not working
Product: Red Hat Enterprise Linux 5 Reporter: Johan Bergström <johan.bergstrom>
Component: bindAssignee: Adam Tkac <atkac>
Status: CLOSED NOTABUG QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: 5.1CC: ovasik
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-09-02 08:20:39 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Johan Bergström 2008-05-22 15:59:49 UTC
Description of problem: When enabling trusted-key for DNSSEC trustchain against
.SE .SE stops answering on any dns queries.


Version-Release number of selected component (if applicable):
bind-9.3.3-10.el5
bind-chroot-9.3.3-10.el5
bind-libs-9.3.3-10.el5
bind-utils-9.3.3-10.el5


How reproducible:
Always.

Steps to Reproduce:
1. Add dnssec-enable yes; to options {} clause in /etc/named.conf
2. Add the trusted-keys entry.
trusted-keys {
"se" 257 3 5
      
"AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWHa+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+jPp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6+N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfOOeJKUkNB8Qc=";
};

3. Try to resolv anything in .SE (www.google.se)
  
Actual results:

Server failure, timeouts different tools report different results. But no tool
can do an actual resolving request.

Expected results:

IP number from the request.

Additional info:

Fedora4 bind version 9.3 works. 
We updated bind with yum against RHN, got version 9.3.4 after update. Problem
still occurs.

After upgrading to 9.4.2-3 (source package at
http://people.redhat.com/atkac/bind/) using trusted-keys and dnssec-validation
works, normal but lookups are incredibly slow, and trying to validate a real
dnssec domain (www.gavle.se) doesn't work.

Comment 1 Adam Tkac 2008-05-28 11:11:55 UTC
Hm, I'm not able to reproduce problem on my test machine (RHEL 5.2 - bind
9.3.4-6.P1.el5 installed there).

Could you please add those lines to logging statement in named.conf, please?

channel dnssec_log {
  file "data/dnssec.log";
  print-time yes;
  print-category yes;
  print-severity yes;
  severity debug 99;
};
category dnssec { dnssec_log; };

and then attach /var/named/data/dnssec.log file when server doesn't respond.

You can also try run
$ dig @catcher-in-the-rye.nic.se. gavle.se +dnssec

from your server to make sure that you don't have problems on the wire. You
should got something like

; <<>> DiG 9.3.4-P1 <<>> @catcher-in-the-rye.nic.se. gavle.se +dnssec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13456
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;gavle.se.			IN	A

;; AUTHORITY SECTION:
gavle.se.		86400	IN	NS	ns2.gavlenet.com.
gavle.se.		86400	IN	NS	ns.gavle.se.
gavle.se.		3600	IN	DS	36157 5 1 D9808271F68AC66E4D9BB003C68D2E667927AFD8
gavle.se.		3600	IN	DS	36157 5 2
4EFF87E0E8E0D58AE8BE00A2E13B1CEA0D7D06EAB152824407D9958A 4DC6B4E9
gavle.se.		3600	IN	RRSIG	DS 5 2 3600 20080603151940 20080527221235 15918 se.
gFpZ8p8sBZ4uZxaF8MT4G5jlJ5WePTIVIY9fQ6Vuk5PuPzL17r2t88+z
INLFSfKMgvNqXo2Tyy4D+ea0RZ35HZ4SbK+jyHEEdkkaN16I4EAmOfKI
TMjKdZLJdouO7z4/tu+kXcCNcr6p+U81SB/DMXeVTArRMCbLZR4SyFZv Bhc=

;; ADDITIONAL SECTION:
ns.gavle.se.		86400	IN	A	83.137.8.21

;; Query time: 54 msec
;; SERVER: 192.36.144.107#53(192.36.144.107)
;; WHEN: Wed May 28 11:10:12 2008
;; MSG SIZE  rcvd: 346

Thanks.

Comment 2 Johan Bergström 2008-09-02 08:03:29 UTC
You can close this bug, it wasn't a bind issue at all, but a communication problem.

Our firewall didn't accept udp packages larger than 1024 bytes, that's why DNSSEC which ofcourse uses EDNS extensions didn't work. We set udp max packet limit size to 4096 now and our problems are gone.

Comment 3 Adam Tkac 2008-09-02 08:20:39 UTC
(In reply to comment #2)
> You can close this bug, it wasn't a bind issue at all, but a communication
> problem.
> 
> Our firewall didn't accept udp packages larger than 1024 bytes, that's why
> DNSSEC which ofcourse uses EDNS extensions didn't work. We set udp max packet
> limit size to 4096 now and our problems are gone.

Thanks for your feedback, closing