Am Thu, 8 Mar 2012 10:10:04 +0300
schrieb mustafa alhussona :
> hi
> i have bind9.9.0 installed manually now i want to start the service using
> the command named i used named -fg to start it and it works, now how i can
> stop it the man named page is encrypted and the options of this command are
On Mar 7, 2012, at 9:15 AM, mustafa alhussona wrote:
> hi
> i have problem with installing bind (i tried 9.7.4,9.8.1,9.9.0 versions)
> service manually on debian squeeze, the problem is the service is installed
> but i cant find the configuration file and there is some error logs, please
> can
You would need to create a custom script to use as your monitor, which does
a lookup of an address that you know will always be in your domain. If that
fails, force-down/inactive the node, and tie this script as a monitor to
the pool holding the DNS server nodes.
You can advertise the /32 containi
On Mar 7, 2012, at 6:23 PM, Mark Andrews wrote:
> Compile in +sigchase support and give it a root key.
Evan Hunt told us (regarding +sigchase) "in its current state it's terrible and
you really shouldn't use it."
I'm not sure who to believe.
> TCP has *never* been optional for DNS. Unfortunat
On linux boxes, adding
options rotate
to the /etc/resolv.conf helps.
Lyle Giese
LCR Computer Services, Inc.
On 03/07/12 06:54, Bostjan Skufca wrote:
Problem is, most of client resolvers (not resolving nameservers, but
resolvers on workstations etc) query first specified nameserver first,
the
In message <7b71a06b-ca32-4e96-9ae0-0c0e29eb1...@yahoo-inc.com>, "Mark K. Petti
t" writes:
> That's a little more output, but when you try it, notice that there's no =
> "dig org. DNSKEY" in the output, which is the query that was hanging in =
> my case.
Compile in +sigchase support and give it a
In message
, Nick Edwards writes:
> On 3/8/12, Nick Edwards wrote:
> > On 3/7/12, Mark Andrews wrote:
> >
> >>> resigned it again as about 3 months using:dnssec-signzone -a -e
> >>> +15724800 -K keys/ -N INCREMENT guilty_domain.here
> >>
> >> You should have fed dnssec-signzone the old sign
On 3/8/12, Nick Edwards wrote:
> On 3/7/12, Mark Andrews wrote:
>
>>> resigned it again as about 3 months using:dnssec-signzone -a -e
>>> +15724800 -K keys/ -N INCREMENT guilty_domain.here
>>
>> You should have fed dnssec-signzone the old signed zone not the unsigned
>> zone.
>>
>> dnssec-sig
On 3/7/12, Mark Andrews wrote:
>> resigned it again as about 3 months using:dnssec-signzone -a -e
>> +15724800 -K keys/ -N INCREMENT guilty_domain.here
>
> You should have fed dnssec-signzone the old signed zone not the unsigned
> zone.
>
> dnssec-signzone -f guilty_domain.here.signed -N
On Tue, Mar 06, 2012 at 07:37:31PM -0800, Mark K. Pettit wrote:
> Please add something to "dig" that replicates the behavior of BIND as
> closely as possible with regards to the many queries it issues as part of
> a DNSSEC-validing resolution.
There's "dig +sigchase", but a) you have to enable it
That's a little more output, but when you try it, notice that there's no "dig
org. DNSKEY" in the output, which is the query that was hanging in my case.
On Mar 6, 2012, at 9:10 PM, Mark Andrews wrote:
>
> dig +trace +qr +comment +question
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dun
thanks everyone for all responses with the great inputs ..
now if I want to put the DNS servers behind LBs, 1) would the LTMs be able to
announce the routes dynamically for the DNS servers, and a VIP can be withdrawn
when the site is gone? 2) would the LTMs be able to detect a DNS service
fai
> There's quite a bit about choosing e in this presentation:
> http://www.esiea-recherche.eu/Slides09/slides_iAWACS09_Erra-Grenier_How-to-compute-RSA-keys.pdf
> However, I don't understand the math, so I can't say whether any of the
> advice is reasonable :(
Interesting document, although I'm no
It seems that several DNSSEC zones are using RSA keys with a public
exponent of 2**32+1, probably because that's the value that the -e
option to dnssec-keygen uses.
While 3 is a perfectly good RSA public exponent, several bugs in
signature verification have been found over the years where a value
> - use algo 7 with NSEC allows you to move to NSEC3 without much hassle
> (but older resolvers won't validate your replies meanwhile)
>
> - use algo 5 with NSEC and you have to do a algorithm rollover first
> when you want to move to NSEC3 (but meanwhile, older resolvers will
> validate your repl
On 3/7/12 9:15 AM, "Barry Margolin" wrote:
> In article ,
> ro...@free.fr wrote:
>> I use bind on my network as DNS Server. Running bind
>> 1:9.6.ESV.R4+dfsg-0+lenny4
>> on Debian Lenny.
>>
>> The setup is quite usual : one master server with one slave server.
>>
>> The slave sync the zone from
On 03-07-12 18:08, Evan Hunt wrote:
>> I also find it a bit strange that BIND decides to go for NSEC, even when
>> the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
>
> There's no difference between algorithm 7 and algorithm 5 (RSASHA1).
> The use of a new algorithm number for a pre
---
mustafa alhussona wants to stay in better touch using some of Google's
coolest new
products.
If you already have Gmail or Google Talk, visit:
http://mail.google.com/mail/b-d5dd238c50-98e2aeea48-2VZCCPdyD-N7g4ZkAsBipin_uOU
You
In article ,
ro...@free.fr wrote:
> Dear community,
>
> I use bind on my network as DNS Server. Running bind
> 1:9.6.ESV.R4+dfsg-0+lenny4
> on Debian Lenny.
>
> The setup is quite usual : one master server with one slave server.
>
> The slave sync the zone from the master.
>
> I discover tha
hi
i have problem with installing bind (i tried 9.7.4,9.8.1,9.9.0 versions)
service manually on debian squeeze, the problem is the service is installed
but i cant find the configuration file and there is some error logs, please
can you suggest a solution for this problem, the installation steps are
> It is not possible to configure NSEC3 as a default in named.conf (on a
> per zone basis), is it? I would welcome such a feature.
I considered it, but bogged down on issues like what to do if you have
nsec3 parameters set a certain way in named.conf, then change them in the
running zone, then res
On Wed, Mar 07, 2012 at 03:35:25PM +, Spain, Dr. Jeffry A. wrote:
> Please post any additional evidence you may have that would further the
> discussion. Thanks. Jeff.
There's quite a bit about choosing e in this presentation:
http://www.esiea-recherche.eu/Slides09/slides_iAWACS09_Erra-Grenie
On Wed, Mar 07, 2012 at 09:30:06AM +0100, Marc Lampo wrote:
> Switch from NSEC to NSEC3 !!!
> This is a statement with potentially huge consequences, IMHO.
I said "NSEC3 to NSEC", actually.
As you noted, switching from NSEC to NSEC3 requires planning: if your
domain uses a DNSKEY algorithm less t
On Mar 7 2012, Bill Owens wrote:
[...]
As Miek discovered, the hard way, .us also uses 2^32+1; my list didn't
include TLDs so there may be others. I'll do another run over lunch today. . .
Based on a scan I did yesterday:
All DNSKEYs in all TLDs use an RSA public exponent of 2^16+1 except fo
> Well, go argue with Adam Langly in the bug report I submitted (and Paul
> quoted in this thread).
You're making an argumentum ad verecundiam, which I can't reasonably pursue. In
the bug report
(http://code.google.com/p/go/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Status%20Stars%20Pr
On Wed, Mar 07, 2012 at 02:43:01PM +, Chris Thompson wrote:
> You can see the BE (2^30+3) ones in the DNSKEYs for dlv.isc.org as
> well as in a number of our own zones (which says either that the keys
> are oldish or that the versions of OpenSSL used are not as up to date
> as they probably
On Wed, Mar 07, 2012 at 02:43:01PM +, Chris Thompson wrote:
> Oh, damn. I have to retract. Or indeed, grovel. It all depends on which
> version of OpenSSL it is linked with, not on the code in dnssec-keygen
> itself. Older versions do indeed generate 2^30+3, but newer ones 2^32+1.
>
> You can
[ Quoting at 14:33 on Mar 7 in "RE: fermat primes
an..." ]
> > Its not about integer overflow, it's about the fact that F5 does not add to
> > the security, but does use up a lot of CPU cycles.
>
> I'd like to study this issue more. Would you please provide a reference that
> discusses your a
On Mar 7 2012, Bill Owens wrote:
On Wed, Mar 07, 2012 at 12:13:35PM +, Chris Thompson wrote:
This is wrong (although I have seen the same thing stated in a number
of other places). When the default public exponent was changed from
3 to 2^16+1 (change 2088) the one selected by -e was changed
> Its not about integer overflow, it's about the fact that F5 does not add to
> the security, but does use up a lot of CPU cycles.
I'd like to study this issue more. Would you please provide a reference that
discusses your assertion that using an F5 public exponent does not add to the
security
On Wed, Mar 07, 2012 at 12:13:35PM +, Chris Thompson wrote:
> This is wrong (although I have seen the same thing stated in a number
> of other places). When the default public exponent was changed from
> 3 to 2^16+1 (change 2088) the one selected by -e was changed from
> 2^16+1 to 2^30+3 ... *n
In message
, Nick Edwards writes:
> I am an old hand at bind, but - DNSSEC Newbie alert :->
>
> I am after clarification on how slaves handle DNSSEC.
>
> I have two slaves, both were stale, like since Feb 9 ! One I directly
> control, the second, I do not, so I can not provide details on how
>
I am an old hand at bind, but - DNSSEC Newbie alert :->
I am after clarification on how slaves handle DNSSEC.
I have two slaves, both were stale, like since Feb 9 ! One I directly
control, the second, I do not, so I can not provide details on how
that one is configured, but given it is a reputab
Problem is, most of client resolvers (not resolving nameservers, but
resolvers on workstations etc) query first specified nameserver first, then
after timeout start with the others. You should create a HA IP for such
uses.
b.
On 7 March 2012 10:23, wrote:
> Dear community,
>
> I use bind on my
On Mar 6 2012, Paul Wouters wrote:
See part of the dicsussion Miek and I had at the golang group:
http://code.google.com/p/go/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Status%20Stars%20Priority%20Owner%20Reporter%20Summary&groupby=&sort=&id=3161
The bug seems to be that dnssec-keygen
On 03/07/2012 09:38 AM, Marco Davids (SIDN) wrote:
AS I understand it, NSEC3 incurs overhead at validating resolvers. That
being the case, it is unfriendly to use it unless you really need it
I don't have a problem with that. It's just that I find the current way
BIND works a bit tricky. I wou
Phil,
On 03/07/12 10:27, Phil Mayers wrote:
> On 03/07/2012 08:50 AM, Marco Davids (SIDN) wrote:
>
>> I also find it a bit strange that BIND decides to go for NSEC, even when
>> the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
>>
> AS I understand it, NSEC3 incurs overhead at vali
On 03/07/2012 08:50 AM, Marco Davids (SIDN) wrote:
I also find it a bit strange that BIND decides to go for NSEC, even when
the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
AS I understand it, NSEC3 incurs overhead at validating resolvers. That
being the case, it is unfriendl
Dear community,
I use bind on my network as DNS Server. Running bind 1:9.6.ESV.R4+dfsg-0+lenny4
on Debian Lenny.
The setup is quite usual : one master server with one slave server.
The slave sync the zone from the master.
I discover that when the master is down I have some trouble to access to
Hi,
It is not possible to configure NSEC3 as a default in named.conf (on a
per zone basis), is it? I would welcome such a feature.
I also find it a bit strange that BIND decides to go for NSEC, even when
the KSK and ZSK are configured with algorithm: 7 (NSEC3RSASHA1).
Thanks.
--
Marco
On 03/0
Switch from NSEC to NSEC3 !!!
This is a statement with potentially huge consequences, IMHO.
Only valid where DNSSEC algorithms allow either method
(like algo #8 and algo #10, unsure about others).
For algorithm like #5, NSEC is implied.
So suggesting that it is easy to switch (between NSEC and N
41 matches
Mail list logo
