Re: dnssec-keygen not responding

[Adam Tkac]

On Wed, Nov 30, 2011 at 12:18:04AM -0500, Alan Clegg wrote:
> On 11/30/2011 12:15 AM, vishesh kumar wrote:
> > Hi All
> > 
> > I am trying to generate keys for signing vishesh.com
> >  domain using following command (for testing purpose)
> > 
> > dnssec-keygen -a RSASHA1 -b 768 -n ZONE vishesh.com .
> > 
> > But its not responding , i waited around 30 minutes but there is no result
> > 
> > Operating system is RHEL6 on VirtualBox 4.1
> 
> You don't have enough entropy in the virtual environment.  You can (if
> you understand the issues surrounding it), use /dev/urandom as your
> random source, or look at installing something like haveged
> (http://freecode.com/projects/haveged) to solve the problem.

Another good solution is to pass "-r keyboard" to dnssec-keygen.

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: dnssec-keygen not responding

[Torsten Segner]

Am Wed, 30 Nov 2011 09:40:44 +0100
schrieb Adam Tkac :

> On Wed, Nov 30, 2011 at 12:18:04AM -0500, Alan Clegg wrote:
> > On 11/30/2011 12:15 AM, vishesh kumar wrote:
> > > Hi All
> > > 
> > > I am trying to generate keys for signing vishesh.com
> > >  domain using following command (for testing purpose)
> > > 
> > > dnssec-keygen -a RSASHA1 -b 768 -n ZONE vishesh.com .
> > > 
> > > But its not responding , i waited around 30 minutes but there is no result
> > > 
> > > Operating system is RHEL6 on VirtualBox 4.1
> > 
> > You don't have enough entropy in the virtual environment.  You can (if
> > you understand the issues surrounding it), use /dev/urandom as your
> > random source, or look at installing something like haveged
> > (http://freecode.com/projects/haveged) to solve the problem.
> 
> Another good solution is to pass "-r keyboard" to dnssec-keygen.
> 
> Regards, Adam
> 

In RHEL there is a RPM package called unuran. 
It's a random number generator daemon using either a piece of hardware or 
/dev/urandom as source. Running this will provide enough entropy to create lots 
of keys.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Phil Mayers]

On 11/29/2011 11:53 PM, Doug Barton wrote:

On 11/29/2011 15:33, Chris Thompson wrote:

With a mixture of small and large zones, signed and unsigned, choosing
sensible values for max-journal-size can become rather tedious (unless
one is prepared to to say "disc space is cheap, make them all").


I'm quite prepared to say that, especially when you include regular
rotation and compression. IME BIND logs compress very nicely, especially
with bz2.


Are we talking about the same thing here? .jnl files, from which IXFR 
and such are generated?

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Phil Mayers]

On 11/29/2011 11:33 PM, Chris Thompson wrote:

With a mixture of small and large zones, signed and unsigned, choosing
sensible values for max-journal-size can become rather tedious (unless
one is prepared to to say "disc space is cheap, make them all ").


We sort of did this accidentally. "max-journal-size" wasn't being set on 
our servers - the .jnl file for "imperial.ac.uk" was nearly 2Gb... oops.


The value I set it to eventually was pretty big - 128M globally - which 
on our biggest zones seems to give ~2 months of history. This is almost 
certainly overkill of a huge magnitude, but disk is relatively cheap!


Not sure how many zones you've got, but we've got ~300 and our total 
"zones/" subdir size is ~1.2Gb - most of that is several large, signed 
zones.



What I would really like is an option that discards increments applied
sufficiently long ago - the expire time for the zone being an obvious
choice. But I do see that the current structure of the journal file
would make that hard to implement.


I wonder if an external tool to "trim" the journal would be an option? 
You'd need a timestamp on records (relying on the RRSIGs mean it only 
works for signed). Not sure about the locking implications.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Doug Barton]

On 11/30/2011 01:23, Phil Mayers wrote:
> On 11/29/2011 11:53 PM, Doug Barton wrote:
>> On 11/29/2011 15:33, Chris Thompson wrote:
>>> With a mixture of small and large zones, signed and unsigned, choosing
>>> sensible values for max-journal-size can become rather tedious (unless
>>> one is prepared to to say "disc space is cheap, make them all").
>>
>> I'm quite prepared to say that, especially when you include regular
>> rotation and compression. IME BIND logs compress very nicely, especially
>> with bz2.
> 
> Are we talking about the same thing here? .jnl files, from which IXFR
> and such are generated?

D'oh! Obviously not, sorry. I've been doing some work on log rotation
lately and apparently it got stuck harder in my brain than I thought. :)

Meanwhile, I still think disk is cheap, and that leaving BIND to do its
thing is probably your best bet.


Doug

-- 

"We could put the whole Internet into a book."
"Too practical."

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Matus UHLAR - fantomas]

On 11/29/2011 11:33 PM, Chris Thompson wrote:

With a mixture of small and large zones, signed and unsigned, choosing
sensible values for max-journal-size can become rather tedious (unless
one is prepared to to say "disc space is cheap, make them all ").


On 30.11.11 09:32, Phil Mayers wrote:
We sort of did this accidentally. "max-journal-size" wasn't being set 
on our servers - the .jnl file for "imperial.ac.uk" was nearly 2Gb... 
oops.


The value I set it to eventually was pretty big - 128M globally - 
which on our biggest zones seems to give ~2 months of history. This 
is almost certainly overkill of a huge magnitude, but disk is 
relatively cheap!


Not sure how many zones you've got, but we've got ~300 and our total 
"zones/" subdir size is ~1.2Gb - most of that is several large, 
signed zones.


Well, that's way too much. The main point of journal is imho to provide 
IXFR, and IXFR is only worth using when its size is smaller than AXFRs.


That means jnl should not get (much) bigger than zone file itself. 
(unless, of course, always the same data gets added/removed/changed).



What I would really like is an option that discards increments applied
sufficiently long ago - the expire time for the zone being an obvious
choice. But I do see that the current structure of the journal file
would make that hard to implement.


I wonder if an external tool to "trim" the journal would be an 
option? You'd need a timestamp on records (relying on the RRSIGs mean 
it only works for signed). Not sure about the locking implications.


I think this is something BIND should take care about.

Does BIND veridy the journal not to exceed usefull size?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam is for losers who can't get business any other way.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Anand Buddhdev]

On 30/11/2011 10:32, Phil Mayers wrote:

> We sort of did this accidentally. "max-journal-size" wasn't being set on
> our servers - the .jnl file for "imperial.ac.uk" was nearly 2Gb... oops.
> 
> The value I set it to eventually was pretty big - 128M globally - which
> on our biggest zones seems to give ~2 months of history. This is almost
> certainly overkill of a huge magnitude, but disk is relatively cheap!

We had a similar issue. One one server, with hundreds of zones, several
of which are updated frequently, we began getting disk space warnings
from our monitoring system. The .jnl files were the culprits.

We have a rather low setting of 10M for our journal size, but it's not
ideal since the rate of change of the zones isn't the same.

I think the default setting of "unlimited" for this option in BIND isn't
a very good one. It can catch a system administrator unaware. On the
other hand, I can't think what default setting the ISC folk could apply.

Anand Buddhdev
RIPE NCC
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Phil Mayers]

On 30/11/11 10:09, Matus UHLAR - fantomas wrote:


Well, that's way too much. The main point of journal is imho to provide


I think this is a decision for each operator to make themselves.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

found a bug in bind9.7.3

[张海阔]

hello, bind-users,
I found a bug at openssl patch in bind 9.7.3.
pk11_active_add function should be called with the active list lock protection 
in pk11_get_private_rsa_key function at hw_pk11so_pub.c file, but it is not 
locked.
the other question is that why pFuncList->C_Finalize is commented in 
pk11_finish funciton at hw_pk11so.c? you said "calling this function may have 
side-effects". I don't know what is the side-effects, can you tall me something 
detail about the side-effects?
Regards
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Matus UHLAR - fantomas]

On 30/11/11 10:09, Matus UHLAR - fantomas wrote:

Well, that's way too much. The main point of journal is imho to provide


On 30.11.11 11:51, Phil Mayers wrote:

I think this is a decision for each operator to make themselves.


I was trying to explain that there are reasonable limits over which 
journalling is useless.  However you have deleted the important p

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"Two words: Windows survives." - Craig Mundie, Microsoft senior strategist
"So does syphillis. Good thing we have penicillin." - Matthew Alton
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Sam Wilson]

In article ,
 Matus UHLAR - fantomas  wrote:

> >On 30/11/11 10:09, Matus UHLAR - fantomas wrote:
> >>Well, that's way too much. The main point of journal is imho to provide
> 
> On 30.11.11 11:51, Phil Mayers wrote:
> >I think this is a decision for each operator to make themselves.
> 
> I was trying to explain that there are reasonable limits over which 
> journalling is useless.  However you have deleted the important p

We may also like to consider whether the journal should be limited by 
the expiry or refresh times of the zone itself.  There is unlikely to be 
huge utility in keeping changes that go back many times further than the 
expiry time.

Sam
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Shumon Huque]

On Wed, Nov 30, 2011 at 11:09:48AM +0100, Matus UHLAR - fantomas wrote:
> Well, that's way too much. The main point of journal is imho to
> provide IXFR, and IXFR is only worth using when its size is smaller
> than AXFRs.
> 
> That means jnl should not get (much) bigger than zone file itself.
> (unless, of course, always the same data gets
> added/removed/changed).

The thing you mention in parentheses is actually fairly common.
If you use DNSSEC, dynamic update, and have BIND do automatic
resigning, then large parts of your zone will frequently get
updated. So the journal file will get large pretty fast ..

I agree with Chris that a better mechanism for cleanup would be 
useful.

-- 
Shumon Huque
University of Pennsylvania.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Phil Mayers]

On 30/11/11 12:10, Matus UHLAR - fantomas wrote:

On 30/11/11 10:09, Matus UHLAR - fantomas wrote:

Well, that's way too much. The main point of journal is imho to provide


On 30.11.11 11:51, Phil Mayers wrote:

I think this is a decision for each operator to make themselves.


I was trying to explain that there are reasonable limits over which
journalling is useless. However you have deleted the important p


Ha! Nice ;o)

Sorry - the point I was trying to make is that some people may find 
journalling beyond the AXFR size useful.


For example: it allows you to use named-journalprint as a primitive time 
machine to see old versions of the zone.


But you are correct, as a default the (binary) size of the zone would be 
a good default for value of max-journal-size.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: make bind-9.7.4-P1 fails when --prefix and --exec-prefix switches are used

[jagan padhi]

Hi,

I am facing this issue while compiling 9.7.4-p1 in solaris 10 box.Please
suggest me what could be the issue.


./configure --prefix=/opt/bind971-NXD-1 --enable-threads
--enable-largefiles --disable-openssl-version-check

configure: WARNING: unrecognized options: --enable-largefiles

checking build system type... sparc-sun-solaris2.10

checking host system type... sparc-sun-solaris2.10

checking whether make sets $(MAKE)... yes

checking for gcc... gcc

checking whether the C compiler works... yes

checking for C compiler default output file name... a.out

checking for suffix of executables...

checking whether we are cross compiling... no

checking for suffix of object files... o

checking whether we are using the GNU C compiler... yes

checking whether gcc accepts -g... yes

checking for gcc option to accept ISO C89... none needed

checking for a sed that does not truncate output... ./configure: line 4579:
/usr/bin/cmp: cannot execute binary file

./configure: line 4579: /usr/bin/cmp: cannot execute binary file

./configure: line 4579: /usr/bin/cmp: cannot execute binary file



checking for grep that handles long lines and -e... /usr/sfw/bin/ggrep

checking for egrep... /usr/sfw/bin/ggrep -E

checking for ld used by gcc... ./configure: line 4752: s%\\%/%g: No such
file or directory

no

configure: error: no acceptable ld found in $PATH


On Fri, Nov 18, 2011 at 1:57 AM, Red Cricket wrote:

> Hi,
>
> I have been working on upgrading from bind-9.7.3-P3 to bind-9.7.4-P1
> to patch for cve-2011-4313.
>
> Here is what I am doing ...
>
> rcricket@dws-rch-rcricket-l:~$ wget
> http://ftp.isc.org/isc/bind9/9.7.4-P1/bind-9.7.4-P1.tar.gz
> ...
> rcricket@dws-rch-rcricket-l:~$ tar -zxf bind-9.7.4-P1.tar.gz
> rcricket@dws-rch-rcricket-l:~$ mkdir BIND_INSTALL_DIR
> rcricket@dws-rch-rcricket-l:~$ cd bind-9.7.4-P1
> rcricket@dws-rch-rcricket-l:~/bind-9.7.4-P1$ ./configure
> --disable-openssl-version-check
> --prefix=/users/rcricket/BIND_INSTALL_DIR
> --exec-prefix=/users/rcricket/BIND_INSTALL_DIR
> ...
> rcricket@dws-rch-rcricket-l:~/bind-9.7.4-P1$ make
> ...
> gcc  -I/users/rcricket/bind-9.7.4-P1 -I./include -I./unix/include -I.
> -I/users/rcricket/bind-9.7.4-P1/lib/lwres/include
> -I../../lib/lwres/unix/include -I../../lib/lwres/include
> -I/users/rcricket/bind-9.7.4-P1/lib/dns/include
> -I../../lib/dns/include
> -I/users/rcricket/bind-9.7.4-P1/lib/bind9/include
> -I../../lib/bind9/include
> -I/users/rcricket/bind-9.7.4-P1/lib/isccfg/include
> -I../../lib/isccfg/include
> -I/users/rcricket/bind-9.7.4-P1/lib/isccc/include
> -I../../lib/isccc/include
> -I/users/rcricket/bind-9.7.4-P1/lib/isc/include -I../../lib/isc
> -I../../lib/isc/include -I../../lib/isc/unix/include
> -I../../lib/isc/nothreads/include -I../../lib/isc/x86_32/include
> -D_GNU_SOURCE -g -O2  -W -Wall -Wmissing-prototypes -Wcast-qual
> -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing  \
> -DVERSION=\"9.7.4-P1\" \
> -DCONFIGARGS="\"'--disable-openssl-version-check'
> '--prefix=/users/rcricket/BIND_INSTALL_DIR'
> '--exec-prefix=/users/rcricket/BIND_INSTALL_DIR'\"" \
>-DNS_LOCALSTATEDIR=\"/users/rcricket/BIND_INSTALL_DIR/var\" \
>-DNS_SYSCONFDIR=\"/users/rcricket/BIND_INSTALL_DIR/etc\" -c ./main.c
> gcc.orig: '--prefix=/users/rcricket/BIND_INSTALL_DIR': No such file or
> directory
> gcc.orig: '--exec-prefix=/users/rcricket/BIND_INSTALL_DIR'": No such
> file or directory
> In file included from ./main.c:62:
> ./include/named/globals.h:68: error: missing terminating " character
> ./include/named/globals.h:68: error: syntax error before ')' token
> make[2]: *** [main.o] Error 1
> make[2]: Leaving directory `/apps/users/rcricket/bind-9.7.4-P1/bin/named'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/apps/users/rcricket/bind-9.7.4-P1/bin'
> make: *** [subdirs] Error 1
>
> If I run configure without the -prefix and -exec-prefix switches make
> completes without error, but I would like to be able to use the
> -prefix and -exec-prefix switches.
>
> Thanks
> Russ
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: make bind-9.7.4-P1 fails when --prefix and --exec-prefix switches are used

[Anand Buddhdev]

On 30/11/2011 17:27, jagan padhi wrote:

> Hi,
> 
> I am facing this issue while compiling 9.7.4-p1 in solaris 10 box.Please
> suggest me what could be the issue.
> 
> 
> ./configure --prefix=/opt/bind971-NXD-1 --enable-threads
> --enable-largefiles --disable-openssl-version-check
> 
> configure: WARNING: unrecognized options: --enable-largefiles

The option is called enable-largefile. There's no 's' at the end.

Regards,

Anand Buddhdev
RIPE NCC
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: make bind-9.7.4-P1 fails when --prefix and --exec-prefix switches are used

[Jeremy C. Reed]

On Wed, 30 Nov 2011, jagan padhi wrote:

> checking build system type... sparc-sun-solaris2.10


> checking for a sed that does not truncate output... ./configure: line 4579:
> /usr/bin/cmp: cannot execute binary file

What does this tell you?

  file /usr/bin/cmp

(Maybe you have /usr/bin/cmp for non-sparc?)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: sub-domain setup

[Dan McDaniel]

On Mon 28.Nov.11 14:39, Doug Barton wrote:

On 11/28/2011 10:20, Dan McDaniel wrote:


I'm setting up a new DNS server. We have two offices linked by a VPN.
I'm trying to decide whether to have everything under a single domain
(example.com) or to split them into sub-domains (office1.example.com,
office2.example.com).

I wondered if there is a consensus on this. What are the pros and cons
of the two different setups?


You haven't given nearly enough information. Roughly how many hosts
would be in each of the 3 zone files? Do the 2 offices share a DHCP
server? Are you doing dynamic updates? Might you ever want to have an
administrative separation between the 2 offices, such that there may be
personnel who have rights to edit one of the zone files, but not all 3?
Is one of the zones likely to be static for long periods of time, but
one or more of the others are fairly dynamic?

Without knowing more about your environment it's hard to answer your
question intelligently. :)


There is already administrative separation. I am responsible for one of
the offices which includes about 30 users.  The other office is smaller
and doesn't really have a proper DNS setup (but I can't fix that at this
point). I want to enable users in my office to look up local hosts as
well as hosts in the other office. The zone in my office will be
dynamically updated by my DHCP server. The zone for the other office
will be static.

One thing that I've noticed is that with a single zone of example.com if
the host is not found (typo or whatever) the query ends up at the
external DNS and comes back with the address of our external web server.
This tends to confuse the users. With a sub-domain the bad query to
typo.office1.example.com just fails and the error is easier to
understand.

I realize that for an environment this small I could completely re-do it
in the future without too much trouble, but I still want to set it up in
accordance with what is considered good practice.

Dan
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Choosing max-journal-size

[Michael Graff]

On Nov 30, 2011, at 4:09 AM, Matus UHLAR - fantomas wrote:

>> On 11/29/2011 11:33 PM, Chris Thompson wrote:
>> I wonder if an external tool to "trim" the journal would be an option? You'd 
>> need a timestamp on records (relying on the RRSIGs mean it only works for 
>> signed). Not sure about the locking implications.

In general, BIND should handle trimming.

> I think this is something BIND should take care about.
> 
> Does BIND veridy the journal not to exceed usefull size?

There are three issues that I see in our journal files:

(1)  The default size is unlimited.
(2)  To shrink the journal, we copy the more recent half (or some part anyway) 
to a new file.  For large journals, this is significant time and I/O.
(3)  Because of (2) and other reasons, even if you set a max journal size, we 
don't always respect it.

(1) is fixable easily.  We could even estimate based on sizes internally to 
BIND.  We may get the guess wrong for some, but I would submit that unlimited 
is ALWAYS wrong.

(2) is harder to fix.  I once proposed we used SQLite for storage, so we could 
expire records very quickly without re-writing the journal files.  I also once 
proposed that we used two files, each of which was 50% of the max size, and 
would just delete the older half when needed.  Either fix is reasonable.

(3) is an admin expectations problem.  If you run 9.4 or earlier still, you are 
aware that our cache size also did not respect the administrator set maximum.  
9.5 and later fixed that, and this is one more case where complete correctness 
of operation interferes with expectations.

We have had journal file issues like this on our road map for some time now.  
However, there always seems to be a more pressing issue.  Perhaps it would be 
possible for some contributed solutions?  If so, contact me directly.  I'm sure 
someone has an intern or programmer to spare for a bit :)

--Michael

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: dnssec-keygen not responding

[Michael Graff]

On Nov 30, 2011, at 3:01 AM, Torsten Segner wrote:
> In RHEL there is a RPM package called unuran. 
> It's a random number generator daemon using either a piece of hardware or 
> /dev/urandom as source. Running this will provide enough entropy to create 
> lots of keys.

I'd be rather wary of keys made from /dev/urandom but I am often times a 
paranoid security freak.

For my VM environment, I bought a USB random source, and share it across the 
VMs with a little daemon I wrote.  Of course, you could just map the RNG into 
the VM you need too, and even move it around.

--Michael


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: found a bug in bind9.7.3

[Michael Graff]

Hello 张海阔,

I've opened a bug ticket for this one.  I don't know that bind-users is a good 
place to continue discussions, but consider perhaps bind-workers (which is more 
for coders).

I'll send you a link to the bug in separate message.

--Michael

On Nov 30, 2011, at 6:09 AM, 张海阔 wrote:

> hello, bind-users,
> 
> I found a bug at openssl patch in bind 9.7.3.
> pk11_active_add function should be called with the active list lock 
> protection in pk11_get_private_rsa_key function at hw_pk11so_pub.c file, but 
> it is not locked.
> 
> the other question is that why pFuncList->C_Finalize is commented in 
> pk11_finish funciton at hw_pk11so.c? you said "calling this function may have 
> side-effects". I don't know what is the side-effects, can you tall me 
> something detail about the side-effects?
> 
> Regards
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: dnssec-keygen not responding

[Mark Elkins]

On Wed, 2011-11-30 at 13:45 -0600, Michael Graff wrote:
> On Nov 30, 2011, at 3:01 AM, Torsten Segner wrote:
> > In RHEL there is a RPM package called unuran. 
> > It's a random number generator daemon using either a piece of hardware or 
> > /dev/urandom as source. Running this will provide enough entropy to create 
> > lots of keys.
> 
> I'd be rather wary of keys made from /dev/urandom but I am often times a 
> paranoid security freak.
> 
> For my VM environment, I bought a USB random source, and share it across the 
> VMs with a little daemon I wrote.  Of course, you could just map the RNG into 
> the VM you need too, and even move it around.
> 
> --Michael

I installed the 'haveged' package, www.irisa.fr/caps/projects/hipsor
Sort of reads 'entropy' from the CPU and feeds it into /dev/random
-- 
  .  . ___. .__  Posix Systems - (South) Africa
 /| /|   / /__   m...@posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496



smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Algorithm 'When to use EDNS0'?

[Mark Elkins]

On Tue, 2011-11-29 at 15:36 +0200, Mark Elkins wrote:
> When does 'EDNS' get brought into the picture?
> A 'dig' with '+dnssec' works just fine (more than 512 bytes over udp) -
> but a dig without '+dnssec' and actually asking for the 'dnskey' records
> for a domain - which is over 512 bytes - does a "Truncated, retrying in
> TCP Mode" on me - even when asking "localhost".

Thanks for the private replies...

All this comes about as I had the expectation that DIG would run in a
similar way to any other 'dns lookup' - which it currently doesn't.
Neither does it have any form of config file. So adding '+dnssec'
obviously adds the '+edns=0' switch. I'm told that in a future software
release that '+edns=0' will be default behaviour - that sounds like a
reasonable thing to do.
-- 
  .  . ___. .__  Posix Systems - (South) Africa
 /| /|   / /__   m...@posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496



smime.p7s
Description: S/MIME cryptographic signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Algorithm 'When to use EDNS0'?

[Mark Andrews]

In message <1322689151.15146.69.ca...@mjelap.posix.co.za>, Mark Elkins writes:
> On Tue, 2011-11-29 at 15:36 +0200, Mark Elkins wrote:
> > When does 'EDNS' get brought into the picture?
> > A 'dig' with '+dnssec' works just fine (more than 512 bytes over udp) -
> > but a dig without '+dnssec' and actually asking for the 'dnskey' records
> > for a domain - which is over 512 bytes - does a "Truncated, retrying in
> > TCP Mode" on me - even when asking "localhost".
> 
> Thanks for the private replies...
> 
> All this comes about as I had the expectation that DIG would run in a
> similar way to any other 'dns lookup' - which it currently doesn't.
> Neither does it have any form of config file.

Actually dig does have a config file.

   It is possible to set per-user defaults for dig via ${HOME}/.digrc.
   This file is read and any options in it are applied before the
   command line arguments.

> So adding '+dnssec'
> obviously adds the '+edns=0' switch. I'm told that in a future software
> release that '+edns=0' will be default behaviour - that sounds like a
> reasonable thing to do.
> -- 
>   .  . ___. .__  Posix Systems - (South) Africa
>  /| /|   / /__   m...@posix.co.za  -  Mark J Elkins, Cisco CCIE
> / |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: dnssec-keygen not responding

[Paul Wouters]

On Wed, 30 Nov 2011, Michael Graff wrote:


On Nov 30, 2011, at 3:01 AM, Torsten Segner wrote:

In RHEL there is a RPM package called unuran.
It's a random number generator daemon using either a piece of hardware or 
/dev/urandom as source. Running this will provide enough entropy to create lots 
of keys.


I'd be rather wary of keys made from /dev/urandom but I am often times a 
paranoid security freak.

For my VM environment, I bought a USB random source, and share it across the 
VMs with a little daemon I wrote.  Of course, you could just map the RNG into 
the VM you need too, and even move it around.


For KVM, the whole virtio was supposed to have fixed this. I've asked related 
developers since
the xen2 days for feeding host /dev/random into the guest. It's still failing 
everywhere :(

Paul
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

RE: dnssec-keygen not responding

[Spain, Dr. Jeffry A.]

> I'd be rather wary of keys made from /dev/urandom but I am often times a 
> paranoid security freak.

Inexpensive USB-attachable RNG: http://www.entropykey.co.uk/

Jeffry A. Spain
Network Administrator
Cincinnati Country Day School

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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