I wrote in an earlier message:
I've been trying out unbound-1.0.1 on a 7.0-STABLE box (2.67 GHz i86,
uniprocessor, 32 bit mode, 2 GB memory).
Don't know what I'm doing wrong so far - but I've been unable to scale
Unbound to more than a couple of hundred q/s. Any more than that and
I get
[EMAIL PROTECTED] wrote:
As a followup: I'm now happily running Unbound (together with Nominum
CNS) in our standard anycast configuration. I've gotten Unbound to
handle our regular query load of 2000 - 2500 q/s just fine.
Don't leave us all in suspense, what did you have to twiddle? :)
Doug
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Brett Glass wrote:
| At 02:24 PM 7/21/2008, Kevin Oberman wrote:
|
| Don't forget that ANY server that caches data, including an end
| system running a caching only server is vulnerable.
|
| Actually, there is an exception to this. A forward
Alfred Perlstein [Tue, Jul 22, 2008 at 07:11:46PM -0700]:
Back in 2003 I tried to set up a shared key IPSEC dhcp
at home, basically I'd just make a key and sneaker-net it
to the hosts that wanted to connect, after about 6 hours
I just gave up and used wep.
Completely off-topic (sorry for
--==79D675BB9A887D4CB823==
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
--On July 23, 2008 10:46:43 AM +1000 Mark Andrews [EMAIL PROTECTED]=20
wrote:
I just played around with it
Le Wed 23/07/2008, Mark Andrews disait
To roll a key signing key. Add the key at a weekly signing.
Wait for the DNSKEY RRset TTL to expire. Send the new
DS/DLV records for the new keys to the parent/DLV operator.
Once the updated parent / DLV operator has updated
Le Wed 23/07/2008, Mark Andrews disait
To roll a key signing key. Add the key at a weekly signing.
Wait for the DNSKEY RRset TTL to expire. Send the new
DS/DLV records for the new keys to the parent/DLV operator.
Once the updated parent / DLV operator has updated
About scripts for automating DNSSEC maintenance, check this out:
http://www.hznet.de/dns/zkt/
There are also some DNSSEC howtos on that site.
We use ZKT for our DNSSEC zones, and everything except KSK rollover
is fully automated. Has been working fine for about half a year now.
Automatic KSK
On 22 Jul 2008, at 23:49, Kevin Oberman wrote:
Someone needs to write a really good tutorial on dnssec. The bits
and
pieces are scattered about the web, but explanations of now to
publish
your keys, to whom they need to be published and what is involved in
the ongoing maintenance are
On 23 Jul 2008, at 4:18, Paul Schmehl wrote:
WRONG.
You need to re-sign the zone an expire period before the
signatures expire. You need to generate new keys periodically
but no where near every 30 days.
OK. I misspoke. I got the 30 days from Andrew
Brett Glass wrote:
At 02:24 PM 7/21/2008, Kevin Oberman wrote:
Don't forget that ANY server that caches data, including an end system
running a caching only server is vulnerable.
Actually, there is an exception to this. A forward only
cache/resolver is only as vulnerable as its
On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote:
I'm curious, is djbdns exploitable, too? Does it randomize
the source ports of UDP queries?
Apparently, djbdns had randomization of the source ports a long
time ago...
Of course, all solutions that randomize ports are really
On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote:
Brett Glass wrote:
At 02:24 PM 7/21/2008, Kevin Oberman wrote:
Don't forget that ANY server that caches data, including an end system
running a caching only server is vulnerable.
Actually, there is an exception to
Clifton Royston wrote:
I also think that modular design of security-sensitive tools is the
way to go, with his DNS tools as with Postfix.
Dan didn't write postfix, he wrote qmail.
If you're interested in a resolver-only solution (and that is not a
bad way to go) then you should evaluate
cpghost wrote:
Yes indeed. If I understand all this correctly, it's because the
transaction ID that has to be sent back is only 2 bytes long,
2 bits, 16 bytes.
and if the query port doesn't change as well with every query, that
can be cracked in milliseconds: sending 65536 DNS queries to a
On Tue, Jul 22, 2008 at 09:37:14AM -0700, Doug Barton wrote:
Clifton Royston wrote:
I also think that modular design of security-sensitive tools is the
way to go, with his DNS tools as with Postfix.
Dan didn't write postfix, he wrote qmail.
I know, but I think qmail sucks. Wietse
On Tue, Jul 22, 2008 at 09:39:20AM -0700, Doug Barton wrote:
cpghost wrote:
Yes indeed. If I understand all this correctly, it's because the
transaction ID that has to be sent back is only 2 bytes long,
2 bits, 16 bytes.
^ Think you mean those the other way!
and if the
Clifton Royston wrote:
On Tue, Jul 22, 2008 at 09:39:20AM -0700, Doug Barton wrote:
cpghost wrote:
Yes indeed. If I understand all this correctly, it's because the
transaction ID that has to be sent back is only 2 bytes long,
2 bits, 16 bytes.
^ Think you mean those the
Doug Barton wrote:
Clifton Royston wrote:
I also think that modular design of security-sensitive tools is the
way to go, with his DNS tools as with Postfix.
Dan didn't write postfix, he wrote qmail.
If you're interested in a resolver-only solution (and that is not a bad
way to go) then
Matthew Seaman wrote:
Are there any plans to enable DNSSEC capability in the resolver built
into FreeBSD?
The server is already capable of it. I'm seriously considering
enabling the define to make the CLI tools (dig/host/nslookup) capable
as well (there is already an OPTION for this in
--On Tuesday, July 22, 2008 09:37:14 -0700 Doug Barton [EMAIL PROTECTED]
wrote:
Clifton Royston wrote:
I also think that modular design of security-sensitive tools is the
way to go, with his DNS tools as with Postfix.
Dan didn't write postfix, he wrote qmail.
I think his point was that
--On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton [EMAIL PROTECTED]
wrote:
Matthew Seaman wrote:
Are there any plans to enable DNSSEC capability in the resolver built
into FreeBSD?
The server is already capable of it. I'm seriously considering enabling the
define to make the CLI tools
If you're interested in a resolver-only solution (and that is not a
bad way to go) then you should evaluate dns/unbound. It is a
lightweight resolver-only server that has a good security model and
already implements query port randomization. It also has the advantage
of being maintained,
Doug Barton wrote:
Matthew Seaman wrote:
Are there any plans to enable DNSSEC capability in the resolver built
into FreeBSD?
The server is already capable of it. I'm seriously considering enabling
the define to make the CLI tools (dig/host/nslookup) capable as well
(there is already an
Date: Tue, 22 Jul 2008 12:52:15 -0500
From: Paul Schmehl [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
--On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton [EMAIL PROTECTED]
wrote:
Matthew Seaman wrote:
Are there any plans to enable DNSSEC capability in the resolver built
into
--On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman [EMAIL PROTECTED]
wrote:
Once you implement DNSSEC you *must* generate keys every 30 days. So,
I think, if you're going to enable it by default, there needs to be a
script in periodic that will do all the magic to change keys every 30
Date: Tue, 22 Jul 2008 15:30:53 -0500
From: Paul Schmehl [EMAIL PROTECTED]
--On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman [EMAIL PROTECTED]
wrote:
Once you implement DNSSEC you *must* generate keys every 30 days. So,
I think, if you're going to enable it by default, there
--On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton [EMAIL PROTECTED]
wrote:
Matthew Seaman wrote:
Are there any plans to enable DNSSEC capability in the resolver built
into FreeBSD?
The server is already capable of it. I'm seriously considering enabling the
define to make
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--enig5488BAD5E4511AF4D0C2864A
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Doug Barton wrote:
Matthew Seaman wrote:
=20
Are there any plans to enable
On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote:
Brett Glass wrote:
At 02:24 PM 7/21/2008, Kevin Oberman wrote:
Don't forget that ANY server that caches data, including an end system
running a caching only server is vulnerable.
Actually, there is an
On Tue, Jul 22, 2008 at 12:52:15PM -0500, Paul Schmehl wrote:
--On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton
[EMAIL PROTECTED] wrote:
Matthew Seaman wrote:
Are there any plans to enable DNSSEC capability in the resolver built
into FreeBSD?
The server is already capable of it. I'm
Jeremy, I can't agree with you more, for some reason
crypto people seem to believe that in order to drive
a car you should have to know how to rebuild a carb.
Makes no sense.
The funny part is that your comparison with setting up
IPsec is the same thing that I compare these things to.
Back in
--On July 23, 2008 10:46:43 AM +1000 Mark Andrews [EMAIL PROTECTED]
wrote:
I just played around with it recently. It's not that easy to
understand initially *and* the trust anchors thing is a royal PITA.
Once you implement DNSSEC you *must* generate keys every 30 days. So,
I thin k,
if
Lots of good discussion on this thread, I'm going to cherry-pick some
things to respond to.
Kevin Oberman wrote:
And, if you are not sure how good a job it does (and I am not), you
should use the OARC test to check how well it works: dig +short
porttest.dns-oarc.net TXT
If the result is not
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
| close the BIND cache poisoning hole?
Brett, et al,
I'll make this simple for you. If you have a server that is running
BIND, update BIND now.
On Monday 21 July 2008 21:14:22 Doug Barton wrote:
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
| close the BIND cache poisoning hole?
Brett, et al,
I'll make this simple for you. If you have a server that is running
BIND, update BIND
From: Max Laier [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 21:38:46 +0200
Sender: [EMAIL PROTECTED]
On Monday 21 July 2008 21:14:22 Doug Barton wrote:
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
| close the BIND cache poisoning
At 02:24 PM 7/21/2008, Kevin Oberman wrote:
Don't forget that ANY server that caches data, including an end system
running a caching only server is vulnerable.
Actually, there is an exception to this. A forward only cache/resolver is
only as vulnerable as its forwarder(s). This is a workaround
On Mon, 21 Jul 2008, Kevin Oberman wrote:
From: Max Laier [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 21:38:46 +0200
Sender: [EMAIL PROTECTED]
On Monday 21 July 2008 21:14:22 Doug Barton wrote:
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
|
On Tuesday 22 July 2008 00:31:53 Charles Sprickman wrote:
On Mon, 21 Jul 2008, Kevin Oberman wrote:
From: Max Laier [EMAIL PROTECTED]
Date: Mon, 21 Jul 2008 21:38:46 +0200
Sender: [EMAIL PROTECTED]
On Monday 21 July 2008 21:14:22 Doug Barton wrote:
Brett Glass wrote:
| Everyone:
|
Date: Sun, 20 Jul 2008 14:22:09 +1000
From: Edwin Groothuis [EMAIL PROTECTED]
Sender: [EMAIL PROTECTED]
On Sat, Jul 19, 2008 at 09:36:38PM -0600, Brett Glass wrote:
At 09:28 PM 7/19/2008, Subhro wrote:
You need to understand the release engineering process of FreeeBSD.
I've been
On Sat, Jul 19, 2008 at 08:30:57PM -0600, Brett Glass wrote:
Everyone:
Will FreeBSD 7.1 be released in time to use it as an upgrade to
close the BIND cache poisoning hole? We'd like to upgrade affected
servers to the latest FreeBSD at the same time that we upgrade
BIND if possible.
Given
Cilton,
Off topic, but could you please tell me (us) the advantages(and
disadvantages) of djbdns over bind?
Thanks
Subhro
On Sun, Jul 20, 2008 at 11:45 PM, Clifton Royston [EMAIL PROTECTED] wrote:
On Sat, Jul 19, 2008 at 08:30:57PM -0600, Brett Glass wrote:
Everyone:
Will FreeBSD 7.1 be
On Sun, Jul 20, 2008 at 09:44:31AM -0700, Kevin Oberman wrote:
[ snip ]
Second, RELENG_7_0 has the patch plus two other security patches. IT IS
NOT STABLE! It is 7.0 with exactly three important security patches and
nothing else.
[ snip ]
I believe the second sentence could be better
Everyone:
Will FreeBSD 7.1 be released in time to use it as an upgrade to
close the BIND cache poisoning hole? We'd like to upgrade affected
servers to the latest FreeBSD at the same time that we upgrade
BIND if possible.
--Brett Glass
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brett Glass wrote:
| Everyone:
|
| Will FreeBSD 7.1 be released in time to use it as an upgrade to
| close the BIND cache poisoning hole? We'd like to upgrade affected
| servers to the latest FreeBSD at the same time that we upgrade
| BIND if
I'd like to install a fully tested 7.1-RELEASE, rather than
a snapshot of 7-STABLE (in which there have, apparently, been
some problems due to driver updates and work on the TCP stack).
Alas, I haven't seen any schedule or to do list for the release
process yet -- just a note saying that
At 09:28 PM 7/19/2008, Subhro wrote:
You need to understand the release engineering process of FreeeBSD.
I've been watching it (and testing release candidates) since 2.x, so
I think I may possibly have some understanding of it by now. ;-)
The release edition is essential created from the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brett Glass wrote:
| I'd like to install a fully tested 7.1-RELEASE, rather than
| a snapshot of 7-STABLE (in which there have, apparently, been
| some problems due to driver updates and work on the TCP stack).
If you presently installed FreeBSD
Brett,
You need to understand the release engineering process of FreeeBSD.
The release edition is essential created from the stabe edition. 7.1R
would not be something new which is *not* present on 7-STABLE today.
In addition, while a particular branch is alive (not declared as end
of life) all
On Sat, Jul 19, 2008 at 09:36:38PM -0600, Brett Glass wrote:
At 09:28 PM 7/19/2008, Subhro wrote:
You need to understand the release engineering process of FreeeBSD.
I've been watching it (and testing release candidates) since 2.x, so
I think I may possibly have some understanding of it by
51 matches
Mail list logo
