Abort in dig after zone transfer

2009-02-16 Thread Chris Thompson

In the mood for bug reporting now ... :-)

Sometimes dig gets into some sort of mess after doing a zone transfer 
from certain hosts, e.g.


$ dig +nocmd +nostats axfr dlv.isc.org @ns-int.isc.org dlv.new

The complete zone is written to the output file, perfectly correct,
but dig then sits there doing nothing. If one uses ctrl-C (SIGINT)
it dies like this:

dighost.c:3353: REQUIRE(sockcount == 0) failed.
Abort (core dumped)

Here's a stack trace from the core file, for what it's worth:

$ pstack core
core 'core' of 13457:   dig +nocmd +nostats axfr dlv.isc.org @ns-int.isc.org
-  lwp# 1 / thread# 1  
febc54d7 _lwp_kill (1, 6) + 7
feb713f3 raise(6) + 1f
feb51709 abort(8047480, 6, 8249a88, febbe196, 8047360, 806db5a) + cd
081830d7 default_callback (81afbcc, d19, 0, 81afbbc) + 5b
0806db5a destroy_libs (8047364, feffb818, feffb818, 8047364, 8047480, 804739c) 
+ c6
08067d95 main (6, 80473a8, 80473c4) + 105
08064b3e _start   (6, 80474e8, 80474ec, 80474f3, 80474fc, 8047501) + 7a
-  lwp# 3 / thread# 3  
febc47fb __lwp_park (82521c8, 8252198, 0) + b
febbf058 cond_wait_queue (82521c8, 8252198, 0) + 3c
febbf50a _cond_wait (82521c8, 8252198) + 64
febbf54c cond_wait (82521c8, 8252198) + 21
febbf585 pthread_cond_wait (82521c8, 8252198) + 1b
0819d78e run  (8252190) + 62
febc44b7 _thr_setup (fea20a00) + 4e
febc47a0 _lwp_start (fea20a00, 0, 0, fea0fff8, febc47a0, fea20a00)
-  lwp# 4 / thread# 4  
febc5037 ioctl(8250260) + 7
febc44b7 _thr_setup (fea21200) + 4e
febc47a0 _lwp_start (fea21200, 0, 0, fe9efff8, febc47a0, fea21200)

This was with the 9.6.0-P1 version, but I've seen it with other versions.

Fetching the signed root zone from na.iana.org also tends to behave
like this.

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Strange results from dnssec-dsfromkey

2009-02-16 Thread Mark Andrews

Looks like a silly bug that will be simple to fix.

In message prayer.1.3.1.0902161618270.29...@hermes-2.csi.cam.ac.uk, Chris 
Thompson writes:
 I don't understand the results I am getting from dnssec-dsfromkey
 (BIND 9.6.0-P1, Solaris 10_x86, Sun Studio 10 C compiler).
 
 For instance:
 
 $ /usr/local/sbin/dnssec-keygen -a RSASHA1 -b 512 -n ZONE -f KSK test
 Ktest.+005+21283
 
 $ cat Ktest.+005+21283.key
 test. IN DNSKEY 257 3 5 
 AwEAAbmcz5O8AzmbwidEoTMkHbaDhr0EfqKsq6WUyXWn5icJgqMTEoBO 
 T03sgCEDXvnMUNthrV6vBIW9sINCLHzrAJc=
 
 $ /usr/local/sbin/dnssec-dsfromkey Ktest.+005+21283
 test. IN DS 26153 5 1 4DB6296434AA1E9C95C6B68AC1A325AFF2BF856A
 test. IN DS 61367 154 2 
 7733D6D7F56602BB709BE521AFB861AEAF522E1A1946AF788EC994C8 259D3882
 
 $ /usr/local/sbin/dnssec-dsfromkey -1 Ktest.+005+21283
 test. IN DS 26153 5 1 4DB6296434AA1E9C95C6B68AC1A325AFF2BF856A
 
 $ /usr/local/sbin/dnssec-dsfromkey -2 Ktest.+005+21283
 test. IN DS 32741 47 2 
 344D72A40621EF9F6C6FF665B6CAA8E6165928E0AA33074668668C88 8364E27F
 
 In that case the SHA256 records are inconsistent, but at least the
 SHA1 ones came out the same each time...
 
 $ /usr/local/sbin/dnssec-keygen -a RSASHA1 -b 1024 -n ZONE -f KSK test
 Ktest.+005+45172
 
 koala:~:2.2166$ cat Ktest.+005+45172.key
 test. IN DNSKEY 257 3 5 
 AwEAAd0QNMsmSdlyOmMCQX95VS/cOVCK18PorGVmpptTz/pZaCKuErxT 
 RLNEnJb1qDw7HoFu2uSs40YhiqI4p/gyBwcK
 Tj3qr+hGLqX1+zQ6Gf5T SQJEMysWgmFrsqxaUx5M1V1HykprwP+td1rTUPktsrRX3y9JhftYjgCr 
 jlxhz2x1
 
 koala:~:2.2167$ /usr/local/sbin/dnssec-dsfromkey Ktest.+005+45172
 test. IN DS 57820 5 1 4154C73FB7759E846C90092E8EF5CE16FB2630C3
 test. IN DS 361 36 2 1F88F1C881EA4353C838C56837161A1719B03CE57FA74015CACD3611 
 9BC82F22
 
 koala:~:2.2168$ /usr/local/sbin/dnssec-dsfromkey -1 Ktest.+005+45172
 test. IN DS 57820 5 1 B05B7CD38865DED8B4C2F3360764DFF6B3C7C86C
 
 koala:~:2.2169$ /usr/local/sbin/dnssec-dsfromkey -2 Ktest.+005+45172
 test. IN DS 60190 254 2 
 85FEA41A86A84F76E067180884E8A86943870F8FE0554DE81E834306 92EE1DEF
 
 ... but this time the SHA1 digests come out differently as well!
 
 Does dnssec-dsfromkey behave properly for others?
 
 -- 
 Chris Thompson
 Email: c...@cam.ac.uk
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users