Your message dated Wed, 13 Oct 2010 22:08:31 +0000
with message-id <[email protected]>
and subject line Re: bind accepts any incomming zone transfers if the tsig key
is not found
has caused the Debian Bug report #554703,
regarding bind accepts any incomming zone transfers if the tsig key is not found
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
554703: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554703
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: bind9
Version: 1:9.6.1.dfsg.P1-3
Severity: critical
Tags: security
Hi.
I think this is quite security critical,... if my observations should
prove wrong, decrease than please priority ;)
When bind is configured to us TSIGs between master and slave when
tranferring a zone, via a
master 1.2.3.4 key somekey;
statement in a slave zone it should probably not accept such incoming
transfers from the master at 1.2.3.4 if somekey is no configured at
all in the local bind.
I does however:
Nov 6 01:10:05 kronecker named[21547]: zone example.com/IN: unable to
find key: a.example.net-b.example.net
Nov 6 01:10:05 kronecker named[21547]: zone example.com/IN: Transfer started.
I think this is quite critical as typos could easily happen, and bind
does not even refuse to start when a key that is referenced somewhere
wasn't declared.
Regards,
Chris.
Perhaps this should be sent to upstream, too.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages bind9 depends on:
ii adduser 3.111 add and remove users and groups
ii bind9utils 1:9.6.1.dfsg.P1-3 Utilities for BIND
ii debconf [debconf-2.0] 1.5.28 Debian configuration
management sy
ii libbind9-50 1:9.6.1.dfsg.P1-3 BIND9 Shared Library used by BIND
ii libc6 2.10.1-5 GNU C Library: Shared libraries
ii libcap2 1:2.17-2 support for
getting/setting POSIX.
ii libdb4.7 4.7.25-8 Berkeley v4.7 Database
Libraries [
ii libdns50 1:9.6.1.dfsg.P1-3 DNS Shared Library used by BIND
ii libgssapi-krb5-2 1.7dfsg~beta3-1 MIT Kerberos runtime
libraries - k
ii libisc50 1:9.6.1.dfsg.P1-3 ISC Shared Library used by BIND
ii libisccc50 1:9.6.1.dfsg.P1-3 Command Channel Library
used by BI
ii libisccfg50 1:9.6.1.dfsg.P1-3 Config File Handling Library used
ii libldap-2.4-2 2.4.17-2 OpenLDAP libraries
ii liblwres50 1:9.6.1.dfsg.P1-3 Lightweight Resolver Library used
ii libssl0.9.8 0.9.8k-5 SSL shared libraries
ii libxml2 2.7.6.dfsg-1 GNOME XML library
ii lsb-base 3.2-23 Linux Standard Base 3.2
init scrip
ii net-tools 1.60-23 The NET-3 networking toolkit
ii netbase 4.37 Basic TCP/IP networking system
bind9 recommends no packages.
Versions of packages bind9 suggests:
ii bind9-doc 1:9.6.1.dfsg.P1-3 Documentation for BIND
ii dnsutils 1:9.6.1.dfsg.P1-3 Clients provided with BIND
ii resolvconf 1.45 name server information handler
pn ufw <none> (no description available)
-- debconf information:
* bind9/different-configuration-file:
* bind9/run-resolvconf: true
* bind9/start-as-user: bind
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
--- End Message ---
--- Begin Message ---
Hi.
As far as I can see this has been probably solved upstream in the
meantime.
I've did about the same setup as before:
- mistyped a key
- disabled all other means that would require encryption (server
statements or so)
If I then initiate a transfer, then I only get (on the slave):
14-Oct-2010 00:00:27.759 general: error: zone test.example/IN: unable to
find key: fooTypoBar
It no longer says it would actually accept the transfer. And the zone's
serial number hasn't change either.
I'm a bit concerned that I've never read in the upstream changelog that
this was fixed,... so perhaps it's just accidentally fixed :/
Maybe we should try to get in contact with them.
Nevertheless, closing it.
Cheers,
Chris.
btw: sorry for forgetting this and not answering.
--- End Message ---
