Possible issue with BIND 9.9.0/9.9.1
Luther, Dan
Dan.Luther at Level3.com
Thu May 31 17:46:05 UTC 2012
Hello,
When running the BIND 9.9.1 with auto-dnssec set to maintain and inline signing, I've run into several instances where non-standard record types become corrupted. This is on a Sun T2000 server, running Solaris 10. I've tested with both BIND 9.9.1 and 9.9.0 with the same results.
Using this zone file:
[root at dns1] /usr/local/dns/dnssec1/zones> cat m.202.216.in-addr.arpa
; m.202.216.in-addr.arpa
$TTL 86400
@ IN SOA dnssec1.Level3.net. dns.level3.net. (
2012052201 ; serial
3600 ; refresh
900 ; retry
2592000 ; expire
86400 ) ; min ttl
; Authoritative Name Servers
@ IN NS dnssec1.Level3.net.
@ IN NS dnssec2.Level3.net.
; Deny all route announcements except those authorized. (RLOCK)
@ IN TYPE65400 \# 0
; 216.202.0.0/16 SRO 3356 (SRO = "Secure Route Origin")
@ IN TYPE65401 \# 4 00000d1c
; 216.202.124.0/23 SRO 21889 (SRO = "Secure Route Origin")
I'm specifically looking at the "TYPE65400" record above.
The configuration file looks as follows:
options {
# General BIND control options
notify yes;
recursion no;
auth-nxdomain no;
zone-statistics yes;
transfer-format many-answers;
# BIND accessibility options
allow-transfer { 209.244.127.174; localhost; };
allow-query { any; };
allow-query-on { any; };
allow-query-cache { any; };
allow-query-cache-on { any; };
# Server identification options
version "hostmaster at Level3.net";
server-id "dns2.newyork1.Level3.net";
hostname "dns2.newyork1.Level3.net";
# Network and interface configuration options
use-v4-udp-ports { range 8192 65535; };
listen-on { 209.244.7.57; };
notify-source 209.244.7.57;
transfer-source 209.244.7.57;
query-source address 209.244.7.57 port *;
interface-interval 5;
use-alt-transfer-source no;
# File system options
directory "/usr/local/dns/dnssec1";
dump-file "dump";
pid-file "pid";
statistics-file "logs/stats";
# DNSSEC options
dnssec-enable yes;
key-directory "keys";
inline-signing yes;
dnssec-loadkeys-interval 60;
# Performance options
minimal-responses yes;
transfers-in 512;
transfers-out 512;
transfers-per-ns 48;
tcp-clients 500;
max-transfer-time-in 10;
max-transfer-time-out 10;
max-refresh-time 43200;
max-retry-time 900;
serial-query-rate 200;
cleaning-interval 2;
min-retry-time 15;
max-cache-ttl 43200;
max-cache-size 256000000;
min-refresh-time 120;
max-ncache-ttl 900;
};
include "/usr/local/dns/etc/bad-clients.conf";
acl query-clients {
192.168.53.0/24;
!bad-clients;
any;
include "/usr/local/dns/dnssec1/conf/named.rndc";
include "/usr/local/dns/etc/named.logging.9.x";
zone "." in {
type hint;
file "/usr/local/dns/etc/root.cache";
};
/* ID zone */
zone "nameserver" in {
type master;
file "/usr/local/dns/etc/nameserver";
};
. . .
zone "m.202.216.in-addr.arpa" in {
type master;
file "zones/m.202.216.in-addr.arpa";
allow-update { localhost; };
auto-dnssec maintain;
inline-signing yes;
key-directory "keys";
check-names ignore;
};
Queries for this record show an obvious corruption:
[root at dns1] /usr/local/dns/dnssec1/zones> dig @dnssec1 m.202.216.in-addr.arpa TYPE65400 +dnssec +multi
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.9.1 <<>> @dnssec1 m.202.216.in-addr.arpa TYPE65400 +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18188
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;m.202.216.in-addr.arpa. IN TYPE65400
;; ANSWER SECTION:
m.202.216.in-addr.arpa. 86400 IN TYPE65400 \# 48830 ( 00000001000151800000FF7800000009000000000000
0000002A4D90000000000000003E0000000000000000
002A51A000000000FFFFFFFFFFFFFFFF000000000000
00000001000000000001000151800000FF7800000009
0000000000000000002A4C00000000000000005A0000
000000000000002A4F7000000000FFFFFFFFFFFFFFFF
000000000000000000010000002A51A0000000000000
00000000000000000000FFFFFFFFFFFFFFFFC00E070E
03124AEE002A4B100060000001300131013101310131
013101300700020406080A0CBEBEBEBEBEBE00000001
000151800000FF780000000900000000000000000036
2FB00000000000000091000000000000000000362E20
. . .
000000000000000000010029DB6000000001BEBEBEBE
0004000000004D580000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
000000BE000000000000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000
000000000000000000000000 )
m.202.216.in-addr.arpa. 86400 IN RRSIG TYPE65400 5 5 86400 (
20120630132728 20120531122728 60792 m.202.216.in-addr.arpa.
kwvclR3r1j24reESiD1oYcQ9026xjflfHrfO0/gt4beG
PTWssGfpT7vDnqYX3xjUgLrYaE3hxzr6wonBHwmrifyQ
nkgnoywE7CE+XVajB9834LCwRzbNT8UAIhL1xsDqsJlr
/7j4f5IiNuAnxj3kFJTFQ0dKsIBKwk64dc6DZIg= )
;; Query time: 275 msec
;; SERVER: 209.244.7.57#53(209.244.7.57)
;; WHEN: Thu May 31 17:35:20 2012
;; MSG SIZE rcvd: 49075
The "MSG SIZE rcvd" status says it all. Additionally, I'm getting sporadic messages where my inline-signed zones have "No signing records found", including this one, and experiencing crashes when trying to transfer these zones to my secondary.
I've experienced this on several other zones, forcing me to revert to the "old school" method of signing zones. Has anyone experienced such an issue, and can I supply more information to help identify what is causing this error, and more importantly, how to fix it?
Dan Luther
Operations Engineer
Systems Operation Engineering
Level 3 Communications
One Technology Center, Tulsa OK 74103
p: 918-547-4370
e: dan.luther at level3.com<mailto:name.name at level3.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-workers/attachments/20120531/7863d190/attachment-0001.html>
More information about the bind-workers
mailing list