Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

call for testers (Re: ISC BIND 9.7.0b1 is now available)

6 views
Skip to first unread message

JINMEI Tatuya / 神明達哉

unread,
Oct 21, 2009, 6:50:00 PM10/21/09
to bind-...@isc.org
Dear beta testers,

At Tue, 20 Oct 2009 20:29:20 +0000,
Evan Hunt <ea...@isc.org> wrote:

> BIND 9.7.0b1 is now available.

[snip]

> - On some platforms, named and other binaries can now print out
> a stack backtrace an assertion failure, to aid in debugging.

I'd like to know platforms for which this feature does NOT work, so
that we can fix the problem (preferably) or disable this feature at
./configure time for such platforms.

To see if it works for your platform, please perform the following
steps:

1. build 9.7.0b1
2. go to the "bind-9.7.0b1/bin/tests" directory
3. % make backtrace_test
4. % ./backtrace_test

On success, "backtrace_test" simply exits without any output (I know
it's not a good UI); if something goes wrong it will dump some warning
messages to stderr and exit with a non-0 exit code. If the test fails
on your platform, please report it to bind9...@isc.org, including
the OS, its version, and hardware architecture (x86, amd64, sparc,
etc).

There are several known defects:
- this feature doesn't work if it's built with libtool
- this doesn't work for Windows (probably obvious)
these cases don't have to be tested.

Thanks,

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

JINMEI Tatuya / 神明達哉

unread,
Oct 21, 2009, 8:18:25 PM10/21/09
to bind-...@isc.org
At Wed, 21 Oct 2009 15:50:00 -0700,
JINMEI Tatuya <jin...@isc.org> wrote:

> On success, "backtrace_test" simply exits without any output (I know
> it's not a good UI); if something goes wrong it will dump some warning
> messages to stderr and exit with a non-0 exit code. If the test fails
> on your platform, please report it to bind9...@isc.org, including
> the OS, its version, and hardware architecture (x86, amd64, sparc,
> etc).

I've seen a couple of prompt reports (thanks!), and these reports
reminded me that I forgot to ask for one more element of the platform:
compiler. Please include which compiler you use with your reports.

Thanks again,

Dave Knight

unread,
Oct 21, 2009, 8:19:59 PM10/21/09
to JINMEI Tatuya / 神明達哉, bind-...@isc.org

On 2009-10-21, at 6:50 PM, JINMEI Tatuya / 神明達哉 wrote:

> Dear beta testers,
>
> At Tue, 20 Oct 2009 20:29:20 +0000,
> Evan Hunt <ea...@isc.org> wrote:
>
>> BIND 9.7.0b1 is now available.
>
> [snip]
>
>> - On some platforms, named and other binaries can now print out
>> a stack backtrace an assertion failure, to aid in debugging.
>
> I'd like to know platforms for which this feature does NOT work, so
> that we can fix the problem (preferably) or disable this feature at
> ./configure time for such platforms.
>
> To see if it works for your platform, please perform the following
> steps:
>
> 1. build 9.7.0b1
> 2. go to the "bind-9.7.0b1/bin/tests" directory
> 3. % make backtrace_test
> 4. % ./backtrace_test
>

> On success, "backtrace_test" simply exits without any output (I know
> it's not a good UI); if something goes wrong it will dump some warning
> messages to stderr and exit with a non-0 exit code.


> If the test fails
> on your platform, please report it to bind9...@isc.org, including
> the OS, its version, and hardware architecture (x86, amd64, sparc,
> etc).

Possibly also useful to report success here so that many people aren't
needlessly repeating the same test.

It passed for me on:

x86_64 / Mac OS X 10.6.1 / Darwin dhcp4.sanxion.org 10.0.0 Darwin
Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009;
root:xnu-1456.1.25~1/RELEASE_I386 i386

x86 / Ubuntu 9.04 / Linux sb 2.6.28-11-server #42-Ubuntu SMP Fri Apr
17 02:48:10 UTC 2009 i686 GNU/Linux

> There are several known defects:
> - this feature doesn't work if it's built with libtool
> - this doesn't work for Windows (probably obvious)
> these cases don't have to be tested.
>
> Thanks,
>

> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.

> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

Dave Knight

unread,
Oct 21, 2009, 8:25:00 PM10/21/09
to JINMEI Tatuya / 神明達哉, bind-...@isc.org

On 2009-10-21, at 8:19 PM, Dave Knight wrote:

> x86_64 / Mac OS X 10.6.1 / Darwin dhcp4.sanxion.org 10.0.0 Darwin
> Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009;
> root:xnu-1456.1.25~1/RELEASE_I386 i386

i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)


> x86 / Ubuntu 9.04 / Linux sb 2.6.28-11-server #42-Ubuntu SMP Fri Apr
> 17 02:48:10 UTC 2009 i686 GNU/Linux

gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3

JINMEI Tatuya / 神明達哉

unread,
Oct 22, 2009, 3:40:06 AM10/22/09
to Dave Knight, bind-...@isc.org
At Wed, 21 Oct 2009 20:19:59 -0400,

Dave Knight <da...@knig.ht> wrote:
>
> > If the test fails
> > on your platform, please report it to bind9...@isc.org, including
> > the OS, its version, and hardware architecture (x86, amd64, sparc,
> > etc).

> Possibly also useful to report success here so that many people aren't
> needlessly repeating the same test.

Yes, that's indeed helpful as we actually plan to take an "opt-in"
approach, that is, enabling it only for those known to work.

This is a list of platforms I've confirmed to work correctly:

- FreeBSD 6.1-RELEASE i386, gcc (GCC) 3.4.4 [FreeBSD] 20050518
- FreeBSD 7.0-RC1 amd64, gcc (GCC) 4.2.1 20070719 [FreeBSD]
- FreeBSD 8.0-RC1 ia64, gcc (GCC) 4.2.1 20070719 [FreeBSD]
- Linux 2.6.25 i686, gcc (Debian 4.3.2-1.1) 4.3.2
- Linux 2.6.18-6-amd64, gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
- SunOS 5.10 i86pc(amd64), Sun C 5.7 2005/01/07
- SunOS 5.10 i86pc(amd64), gcc (GCC) 3.4.2 (producing 32-bit code)

In general, I expect it should work on

- most x86/amd64/IA64 + gcc platforms (regardless of OS)
- most Linux variants (assuming the compiler is gcc, regardless of
machine arch)

So, if it does NOT work on a platform that matches the above
condition, it's good to know. Likewise, if it DOES works on a
platform that doesn't match the condition, it's also a good input.
Other results, which are actually expected but not yet confirmed, are
also appreciated.

Thanks once again,

Sebastian Tymków

unread,
Oct 22, 2009, 4:13:31 AM10/22/09
to JINMEI Tatuya / 神明達哉, bind-...@isc.org
~/bind-9.7.0b1/bin/tests# uname -rna
FreeBSD hostname 7.2-STABLE FreeBSD 7.2-STABLE #0: Tue Aug 11 20:18:22 UTC 2009     root@hostname:/usr/obj/usr/src/sys/GENERIC  amd64
[10:09] ttyp0/0           {861}~/bind-9.7.0b1/bin/tests# gcc --version

gcc (GCC) 4.2.1 20070719  [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~/bind-9.7.0b1/bin/tests# uname -rna
FreeBSD hostname 7.2-RELEASE-p3 FreeBSD 7.2-RELEASE-p3 #1: Fri Aug  7 09:47:09 CEST 2009     root@hostname:/usr/obj/usr/src/sys/GENERIC  i386
[10:12] ttyp0/0                                                                 root@hostname{1585}~/bind-9.7.0b1/bin/tests# gcc --version

gcc (GCC) 4.2.1 20070719  [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Anatoly Pugachev

unread,
Oct 22, 2009, 5:48:23 AM10/22/09
to JINMEI Tatuya / 神明達哉, bind-...@isc.org

JINMEI,

we're not using sparc for our bind installations, but this is a feedback
on your 'call for testers' (bind compilation went successfully on both
compilers):

solaris 10 sparc, sun studio 12u1 compiler:

$ uname -a
SunOS chuck 5.10 Generic_141414-10 sun4u sparc SUNW,Sun-Fire-V440
$ cc -V
cc: Sun C 5.10 SunOS_sparc 2009/06/03
[tests]$ ./backtrace_test
isc_backtrace_gettrace failed: not implemented
[tests]$ echo $?
1

solaris 10 sparc, sun gcc compiler:

$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

[tests]$ ./backtrace_test
isc_backtrace_gettrace failed: not implemented


Anatoly Pugachev

unread,
Oct 22, 2009, 8:04:36 AM10/22/09
to JINMEI Tatuya / 神明達哉, bind-...@isc.org

Solaris 10 sparc running on T5120

$ uname -a
SunOS hosting1 5.10 Generic_137111-04 sun4v sparc SUNW,SPARC-Enterprise-T5120


$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with:
/sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

$ ./backtrace_test
isc_backtrace_gettrace failed: not implemented

$ echo $?
1


Debian 5 sparc running on Sun E250

$ gcc -v
Using built-in specs.
Target: sparc-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc
--enable-mpfr --with-cpu=v8 --with-long-double-128
--enable-checking=release --build=sparc-linux-gnu --host=sparc-linux-gnu
--target=sparc-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1.1)
$ uname -a
Linux squat 2.6.26-2-sparc64-smp #1 SMP Sun Jun 21 05:58:06 UTC 2009 sparc64 GNU/Linux
$ ./backtrace_test
isc_backtrace_gettrace failed: not found
$ echo $?
1

Jeremy C. Reed

unread,
Oct 22, 2009, 9:51:47 AM10/22/09
to bind-...@isc.org
> > Possibly also useful to report success here so that many people aren't
> > needlessly repeating the same test.

- NetBSD 4.99.62 amd64, gcc 4.1.3 20080202 prerelease (NetBSD nb1 20080202)

- NetBSD 5.0.0_PATCH i386, pcc 0.9.9 (HEAD) for i386-unknown-netbsdelf5.0.0.

Gerry Scott

unread,
Oct 22, 2009, 10:09:12 AM10/22/09
to bind-...@isc.org
Backtrace executes successfully on the latest build of OpenSolaris for SPARC
(snv_125) with gcc version 3.4.6

# uname -a
SunOS nemesis 5.11 snv_125 sun4u sparc SUNW, 5-slot Sun Enterprise E3500

# gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.6

Regards,

-----Original Message-----
From: bind-user...@lists.isc.org
[mailto:bind-user...@lists.isc.org] On Behalf Of JINMEI Tatuya / ????
Sent: Wednesday, October 21, 2009 8:18 PM
To: bind-...@isc.org
Subject: Re: call for testers (Re: ISC BIND 9.7.0b1 is now available)

At Wed, 21 Oct 2009 15:50:00 -0700,
JINMEI Tatuya <jin...@isc.org> wrote:

> On success, "backtrace_test" simply exits without any output (I know
> it's not a good UI); if something goes wrong it will dump some warning

> messages to stderr and exit with a non-0 exit code. If the test fails


> on your platform, please report it to bind9...@isc.org, including
> the OS, its version, and hardware architecture (x86, amd64, sparc,
> etc).

I've seen a couple of prompt reports (thanks!), and these reports


reminded me that I forgot to ask for one more element of the platform:
compiler. Please include which compiler you use with your reports.

Thanks again,

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

JINMEI Tatuya / 神明達哉

unread,
Oct 26, 2009, 4:33:11 AM10/26/09
to gsco...@gmail.com, bind-...@isc.org
At Thu, 22 Oct 2009 10:09:12 -0400,
"Gerry Scott" <gsco...@gmail.com> wrote:

> Backtrace executes successfully on the latest build of OpenSolaris for SPARC
> (snv_125) with gcc version 3.4.6
>
> # uname -a
> SunOS nemesis 5.11 snv_125 sun4u sparc SUNW, 5-slot Sun Enterprise E3500
>
> # gcc -v
> Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.10/3.4.6/specs
> Configured with: ../configure --with-as=/usr/ccs/bin/as
> --with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
> Thread model: posix
> gcc version 3.4.6

Thanks for testing. This is an interesting result...I didn't expect
it works for SunOS + sparc. Can you identify if your system has a
"backtrace()" library function in libc? Does your system have
/usr/include/execinfo.h?

Gregory Hicks

unread,
Oct 26, 2009, 10:09:32 AM10/26/09
to bind-...@isc.org, jin...@isc.org

> Date: Wed, 21 Oct 2009 15:50:00 -0700
> From: JINMEI Tatuya / $B?@L@C#:H (B <jin...@isc.org>

>
>
> 1. build 9.7.0b1
> 2. go to the "bind-9.7.0b1/bin/tests" directory
> 3. % make backtrace_test
> 4. % ./backtrace_test

metis% uname -a
SunOS metis 5.9 Generic_122300-31 sun4u sparc SUNW,Ultra-1

metis% make backtrace_test
gcc -I/home/ghicks/incoming/bind/bind-9.7.0b1
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/dns/include
-I../../lib/dns/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isccfg/include
-I../../lib/isccfg/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-D_REENTRANT -DBIND9 -D_XPG4_2 -D__EXTENSIONS__ -g -W -Wall
-Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
-Wpointer-arith -fno-strict-aliasing -o backtrace_test_nosymtbl \
backtrace_test.c ../../lib/isc/libisc.a -L/usr/local/ssl/lib
-R/usr/local/ssl/lib -R/usr/local/ssl/lib -lcrypto -ldl -lnsl -lsocket
-lpthread -lthread
#first step: create a first symbol table
rm -f symtbl.c
if test X/usr/bin/perl != X; then \
/usr/bin/perl ../../util/mksymtbl.pl \
backtrace_test_nosymtbl; else \
cp ../../lib/isc/backtrace-emptytbl.c symtbl.c; fi
#second step: build a binary with the first symbol table
gcc -I/home/ghicks/incoming/bind/bind-9.7.0b1
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/dns/include
-I../../lib/dns/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isccfg/include
-I../../lib/isccfg/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-D_REENTRANT -DBIND9 -D_XPG4_2 -D__EXTENSIONS__ -g -W -Wall
-Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
-Wpointer-arith -fno-strict-aliasing \
-o backtrace_test0 backtrace_test.c symtbl.c \
../../lib/isc/libisc-nosymtbl.a -L/usr/local/ssl/lib
-R/usr/local/ssl/lib -R/usr/local/ssl/lib -lcrypto -ldl -lnsl -lsocket
-lpthread -lthread
rm -f symtbl.c
#third step: create a second symbol table
if test X/usr/bin/perl != X; then \
/usr/bin/perl ../../util/mksymtbl.pl backtrace_test0; else \
cp ../../lib/isc/backtrace-emptytbl.c symtbl.c; fi
#fourth step: build the final binary
rm -f backtrace_test0
gcc -I/home/ghicks/incoming/bind/bind-9.7.0b1
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/dns/include
-I../../lib/dns/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isc/include
-I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include
-I../../lib/isc/pthreads/include -I../../lib/isc/noatomic/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/isccfg/include
-I../../lib/isccfg/include
-I/home/ghicks/incoming/bind/bind-9.7.0b1/lib/lwres/include
-I../../lib/lwres/unix/include -I../../lib/lwres/include
-D_REENTRANT -DBIND9 -D_XPG4_2 -D__EXTENSIONS__ -g -W -Wall
-Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat
-Wpointer-arith -fno-strict-aliasing \
-o backtrace_test backtrace_test.c symtbl.c
../../lib/isc/libisc-nosymtbl.a -L/usr/local/ssl/lib
-R/usr/local/ssl/lib -R/usr/local/ssl/lib -lcrypto -ldl -lnsl -lsocket
-lpthread -lthread
rm -f symtbl.c
metis% ./backtrace_test
isc_backtrace_gettrace failed: not implemented
metis%

>
> On success, "backtrace_test" simply exits without any output (I know
> it's not a good UI); if something goes wrong it will dump some warning
> messages to stderr and exit with a non-0 exit code. If the test fails
> on your platform, please report it to bind9...@isc.org, including
> the OS, its version, and hardware architecture (x86, amd64, sparc,
> etc).
>

> There are several known defects:
> - this feature doesn't work if it's built with libtool
> - this doesn't work for Windows (probably obvious)
> these cases don't have to be tested.
>
> Thanks,
>

> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.

> _______________________________________________
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

---------------------------------------------------------------------
Gregory Hicks | Principal Systems Engineer
| Direct: 408.569.7928

People sleep peaceably in their beds at night only because rough men
stand ready to do violence on their behalf -- George Orwell

The price of freedom is eternal vigilance. -- Thomas Jefferson

"The best we can hope for concerning the people at large is that they
be properly armed." --Alexander Hamilton

Gerry Scott

unread,
Oct 26, 2009, 11:42:53 AM10/26/09
to JINMEI Tatuya / ????, bind-...@lists.isc.org
JINMEI,

OpenSolaris build 125 includes execinfo.h within the /usr/include directory.
Also, backtrace() functionality has been included within the OS since build
63.

http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6536146

Regards,

Gerry Scott
President and Principal Engineer
WAN Systems
Email: gsc...@wansyseng.com

"Empowering businesses with efficient, effective and secure local, wide area
and Internet infrastructure. Customer satisfaction is key to the
bottom-line; the network is key to providing the customer experience".

-----Original Message-----
From: JINMEI Tatuya / ???? [mailto:jin...@isc.org]
Sent: Monday, October 26, 2009 4:33 AM
To: gsco...@gmail.com
Cc: bind-...@isc.org
Subject: Re: call for testers (Re: ISC BIND 9.7.0b1 is now available)

---

JINMEI Tatuya / 神明達哉

unread,
Oct 27, 2009, 3:16:17 AM10/27/09
to gsco...@gmail.com, bind-...@lists.isc.org
At Mon, 26 Oct 2009 11:42:53 -0400,
"Gerry Scott" <gsco...@gmail.com> wrote:

> OpenSolaris build 125 includes execinfo.h within the /usr/include directory.
> Also, backtrace() functionality has been included within the OS since build
> 63.
>
> http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6536146

Okay, that's good know. Thanks,

Stephane Bortzmeyer

unread,
Oct 28, 2009, 10:15:43 AM10/28/09
to Evan Hunt, bind-...@isc.org
On Tue, Oct 20, 2009 at 08:29:20PM +0000,
Evan Hunt <ea...@isc.org> wrote
a message of 836 lines which said:

> BIND 9.7.0b1 is now available.

Apparently, support for the new algorithms RSASHA256 and RSASHA512 is
not included? Is it planned for 9.7 or shall I wait 9.8?

% bind/bin/dnssec/dnssec-keygen -a RSASHA256 -b 2048 -r /dev/urandom example.net
dnssec-keygen: fatal: unknown algorithm RSASHA256

Evan Hunt

unread,
Oct 28, 2009, 10:33:22 AM10/28/09
to Stephane Bortzmeyer, bind-...@isc.org
> Apparently, support for the new algorithms RSASHA256 and RSASHA512 is
> not included? Is it planned for 9.7 or shall I wait 9.8?

That will be in 9.7.0b2.

--
Evan Hunt -- ea...@isc.org
Internet Systems Consortium, Inc.

Chris Thompson

unread,
Oct 28, 2009, 11:17:54 AM10/28/09
to Evan Hunt, Bind Users Mailing List
On Oct 28 2009, Evan Hunt wrote:

>> Apparently, support for the new algorithms RSASHA256 and RSASHA512 is
>> not included? Is it planned for 9.7 or shall I wait 9.8?
>
>That will be in 9.7.0b2.

You aren't going to wait for the RFC? - it doesn't seem to be out yet.
Or maybe you are predicting that it will be out before 9.7.0b2 is...

--
Chris Thompson
Email: ce...@cam.ac.uk

Stephane Bortzmeyer

unread,
Oct 28, 2009, 11:22:22 AM10/28/09
to Chris Thompson, Bind Users Mailing List
On Wed, Oct 28, 2009 at 03:17:54PM +0000,
Chris Thompson <ce...@cam.ac.uk> wrote
a message of 13 lines which said:

> You aren't going to wait for the RFC?

It is in AUTH48 (the last step before publication, theoretically
meaning that the people involved have 48 h to make remarks).

After all, ldns already has it :-)

% ldns-keygen -a RSASHA256 vachement-secure.example
Kvachement-secure.example.+008+23094

% cat Kvachement-secure.example.+008+23094.key
vachement-secure.example. 3600 IN DNSKEY 256 3 8 \
AwEAAc87fkhQ3RehZ9AWUtataphm6Ku+DLKgtUPp/Zi0mwhtDN36oWBhzUt5a82Zeat4zsbC6W
jIDWWqOx33cWh3ISMKDK0cOu1kMRCZTXS98WoSA0TgfMBdGdaK/Z+yLX+COq8HL72gBDG/RuDqIOwdtC
BhbDluIwafzPAw3l2rIEiR \
;{id = 23094 (zsk), size = 1024b}

Evan Hunt

unread,
Oct 28, 2009, 4:02:37 PM10/28/09
to bind-...@lists.isc.org
> You aren't going to wait for the RFC? - it doesn't seem to be out yet.
> Or maybe you are predicting that it will be out before 9.7.0b2 is...

It's out now (RFC 5702), so this is a moot point--but we were mainly
waiting for IANA to pick the final codepoints, not so much for the
RFC to be finalized.

Chris Thompson

unread,
Oct 28, 2009, 5:51:33 PM10/28/09
to Evan Hunt, Bind Users Mailing List
On Oct 28 2009, Evan Hunt wrote:

>> You aren't going to wait for the RFC? - it doesn't seem to be out yet.
>> Or maybe you are predicting that it will be out before 9.7.0b2 is...
>
>It's out now (RFC 5702), so this is a moot point--but we were mainly
>waiting for IANA to pick the final codepoints, not so much for the
>RFC to be finalized.

Will you be adding RSASHA256 support in the 9.5.x and 9.6.x series? It
might be a bit optimistic to expect everyone to move to 9.7.x by 2010-07-01,
if that's when the root zone is going to be *really* signed (with RSASHA256,
according to current reports).

Evan Hunt

unread,
Oct 28, 2009, 6:11:21 PM10/28/09
to bind-...@lists.isc.org

> Will you be adding RSASHA256 support in the 9.5.x and 9.6.x series? It
> might be a bit optimistic to expect everyone to move to 9.7.x by 2010-07-01,
> if that's when the root zone is going to be *really* signed (with RSASHA256,
> according to current reports).

Not 9.5.x, as it lacks NSEC3 support.

Adding SHA-2 to 9.6.x would violate our policy of making major
functional changes only in major releases, so I don't expect we'll
do that. Given the odd circumstances you mentioned, I won't say for
certain that we won't--but I doubt it.

9.7.0 is going to be final in a little over a month, which is fortunate
timing.

Stephane Bortzmeyer

unread,
Oct 29, 2009, 4:24:48 AM10/29/09
to Evan Hunt, bind-...@isc.org
On Tue, Oct 20, 2009 at 08:29:20PM +0000,
Evan Hunt <ea...@isc.org> wrote
a message of 836 lines which said:

> - Support for RFC 5011 automated trust anchor maintenance (see
> README.rfc5011 for additional details).

Seems to work fine, thanks.

With:

managed-keys {
"se." initial-key 257 3 5
"AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ
...
// key id = 8779
};

I indeed get the new key, 49678

29-Oct-2009 09:23:07.275 zone managed-keys.bind/IN/_meta: loaded serial 5

Stephane Bortzmeyer

unread,
Nov 2, 2009, 6:38:31 AM11/2/09
to Evan Hunt, bind-...@isc.org
On Thu, Oct 29, 2009 at 09:24:48AM +0100,
Stephane Bortzmeyer <bortz...@nic.fr> wrote
a message of 25 lines which said:

> > - Support for RFC 5011 automated trust anchor maintenance (see
> > README.rfc5011 for additional details).

Hmmm, it suddenly had a problem:

02-Nov-2009 10:59:14.945 zone managed-keys.bind/IN/_meta: loaded serial 156
...
02-Nov-2009 11:26:35.154 malformed transaction: managed-keys.bind.jnl last serial 157 != transaction first serial 156
02-Nov-2009 11:26:35.154 zone managed-keys.bind/IN/_meta: keyfetch_done:dns_journal_write_transaction -> unexpected error
...
02-Nov-2009 11:27:04.198 malformed transaction: managed-keys.bind.jnl last serial 158 != transaction first serial 157
02-Nov-2009 11:27:04.198 zone managed-keys.bind/IN/_meta: keyfetch_done:dns_journal_write_transaction -> unexpected error

Is it serious? The file managed-keys.bind looks normal.

Evan Hunt

unread,
Nov 2, 2009, 1:47:56 PM11/2/09
to Stephane Bortzmeyer, bind-...@isc.org
> Is it serious? The file managed-keys.bind looks normal.

It's concerning. How many 5011-maintained zones are you running? Can I
see your managed-keys.bind file?

I would expect the result of this to be that keys are not properly updated
in managed-keys.bind until the problem with committing to the journal has
gone away. If it persists for more than one or two events, restart named.
If that doesn't fix it, delete managed-keys.bind.jnl and restart named
again.

I don't know how the journal's serial number would have gotten out of sync
like that. I'll have to look closer.

0 new messages