On 2011-01-24 20.29, Henning Brauer wrote:
* Oliver Peter li...@peter.de.com [2011-01-24 15:13]:
On Mon, Jan 24, 2011 at 01:33:53PM +0100, Henning Brauer wrote:
* Oliver Peter li...@peter.de.com [2011-01-24 11:56]:
The tcp option in resolv.conf might be reasonable for a single workstation
but
On Sun, Jan 23, 2011 at 08:06:09PM +, Kevin Chadwick wrote:
On Sat, 15 Jan 2011 06:28:51 -0500
Josh Smith juice...@gmail.com wrote:
tounge in cheek flame
I've got to say I'm suprised the dns server in the base system of the
worlds most secure OS is not able to validate dnssec responses
* Oliver Peter li...@peter.de.com [2011-01-24 11:56]:
The tcp option in resolv.conf might be reasonable for a single workstation
but due to the protocol overhead not appropriate for larger networks / many
clients.
people keep claiming this bullshit. remains bullshit.
--
Henning Brauer,
On Monday, January 24, 2011, Henning Brauer lists-open...@bsws.de wrote:
* Oliver Peter li...@peter.de.com [2011-01-24 11:56]:
The tcp option in resolv.conf might be reasonable for a single workstation
but due to the protocol overhead not appropriate for larger networks / many
clients.
On Mon, Jan 24, 2011 at 01:33:53PM +0100, Henning Brauer wrote:
* Oliver Peter li...@peter.de.com [2011-01-24 11:56]:
The tcp option in resolv.conf might be reasonable for a single workstation
but due to the protocol overhead not appropriate for larger networks / many
clients.
people
On Mon, Jan 24, 2011 at 07:52:59AM -0500, Josh Smith wrote:
On Monday, January 24, 2011, Henning Brauer lists-open...@bsws.de wrote:
* Oliver Peter li...@peter.de.com [2011-01-24 11:56]:
The tcp option in resolv.conf might be reasonable for a single workstation
but due to the protocol
Josh Smith juice...@gmail.com wrote:
I agree the tcp option in resolv.conf looks great and I'll be enabling
it on my obsd clients but, correct me if I am wrong, this will do
little to help protect the non obsd clients using my recursive
resolvers.
You can use IPsec to protect the
* Oliver Peter li...@peter.de.com [2011-01-24 15:13]:
On Mon, Jan 24, 2011 at 01:33:53PM +0100, Henning Brauer wrote:
* Oliver Peter li...@peter.de.com [2011-01-24 11:56]:
The tcp option in resolv.conf might be reasonable for a single workstation
but due to the protocol overhead not
On Mon, Jan 24, 2011 at 7:52 AM, Josh Smith juice...@gmail.com wrote:
I agree the tcp option in resolv.conf looks great and I'll be enabling
it on my obsd clients but, correct me if I am wrong, this will do
little to help protect the non obsd clients using my recursive
resolvers.
It doesn't
On Mon, 24 Jan 2011 15:13:47 -0500
Ted Unangst ted.unan...@gmail.com wrote:
TCP may help talking to a far away DNS server over the internet, but
honestly, that's an unusual scenario and better handled by a VPN.
Oy, thats where the automacigal transport layer ipsec from ipv6 enters
the stage,
On Thu, Jan 13, 2011 at 09:05:01PM -0500, Josh Smith wrote:
Has anyone had any luck configuring the bind included with 4.7 (named
-v indicates it is 9.4.2-p2) as a DNSSEC validating resolver? Some
digging around the web indicates it might be to old to handle this
properly. If so is the version
On 01/23/2011 02:06 PM, Kevin Chadwick wrote:
On Sat, 15 Jan 2011 06:28:51 -0500
Josh Smithjuice...@gmail.com wrote:
tounge in cheek flame
I've got to say I'm suprised the dns server in the base system of the
worlds most secure OS is not able to validate dnssec responses
/tounge in cheek
On Mon, Jan 24, 2011 at 5:03 PM, Corey clinge...@gmail.com wrote:
snip
Debate indeed; it potentially creates new problems. B See here
(http://dnscurve.org/nsec3walker.html) and here
(http://dnscurve.org/amplification.html) for examples. B It's Dan
Bernstein's
writing, so it's definitely an
On Sat, 15 Jan 2011 06:28:51 -0500
Josh Smith juice...@gmail.com wrote:
tounge in cheek flame
I've got to say I'm suprised the dns server in the base system of the
worlds most secure OS is not able to validate dnssec responses
/tounge in cheek flame
Actually there is much debate about how
On 1/15/11 12:28 PM, Josh Smith wrote:
I've got to say I'm suprised the dns server in the base system of the
worlds most secure OS is not able to validate dnssec responses
pkg_add unbound and you're done. If you think you are that smart to use
DNSSEC, then you should also be that smart to run
On Mon, Jan 17, 2011 at 6:51 AM, Oliver Peter li...@peter.de.com wrote:
On 1/15/11 12:28 PM, Josh Smith wrote:
I've got to say I'm suprised the dns server in the base system of the
worlds most secure OS is not able to validate dnssec responses
pkg_add unbound and you're done. B If you think
On 2011-01-14, Brynet bry...@gmail.com wrote:
BIND10 will be written in a combination of Python and C++, not really a
suitable upgrade for OpenBSD's base resolver/nameserver.
Don't forget it uses boost! :-)
(And for those who are wondering, no this is not a joke)
On 2011-01-14, Josh Smith juice...@gmail.com wrote:
Has anyone had any luck configuring the bind included with 4.7 (named
-v indicates it is 9.4.2-p2) as a DNSSEC validating resolver? Some
digging around the web indicates it might be to old to handle this
properly. If so is the version
On 2011-01-14, Martin Schr?der mar...@oneiros.de wrote:
2011/1/14 Chris Cappuccio ch...@nmedia.net:
nsd is already part of the tree and unbound will join it at some point to
replace bind. they are well documented, fairly easy to use, and unbound is
available through ports. use it.
But a
On Saturday, January 15, 2011, Stuart Henderson s...@spacehopper.org wrote:
On 2011-01-14, Josh Smith juice...@gmail.com wrote:
Has anyone had any luck configuring the bind included with 4.7 (named
-v indicates it is 9.4.2-p2) as a DNSSEC validating resolver? B Some
digging around the web
On Thu, 13 Jan 2011 19:51:48 -0800
Chris Cappuccio ch...@nmedia.net wrote:
nsd is already part of the tree and unbound will join it at some
point to replace bind.
Is it going to happen between 4.9 - 4.10 (5.0)?
--
With best regards,
Gregory Edigarov
2011/1/14 Chris Cappuccio ch...@nmedia.net:
nsd is already part of the tree and unbound will join it at some point to
replace bind. they are well documented, fairly easy to use, and unbound is
available through ports. use it.
But a DNSSSEC validiating resolver should be in base, not ports.
Date: Fri, 14 Jan 2011 10:06:07 +0100
Subject: Re: DNSSEC validating resolver
From: mar...@oneiros.de
To: misc@openbsd.org
2011/1/14 Chris Cappuccio ch...@nmedia.net:
nsd is already part of the tree and unbound will join it at some point to
replace bind. they are well documented, fairly
On 1/14/11 10:06 AM, Martin Schrvder wrote:
2011/1/14 Chris Cappuccio ch...@nmedia.net:
nsd is already part of the tree and unbound will join it at some point to
replace bind. they are well documented, fairly easy to use, and unbound is
available through ports. use it.
But a DNSSSEC
On Thu, Jan 13, 2011 at 10:51 PM, Chris Cappuccio ch...@nmedia.net wrote:
nsd is already part of the tree and unbound will join it at some point to
replace bind. B they are well documented, fairly easy to use, and unbound
is
available through ports. use it.
Chris,
Are you suggesting that
On Fri, Jan 14, 2011 at 4:33 AM, Oliver Peter li...@peter.de.com wrote:
On 1/14/11 10:06 AM, Martin Schrvder wrote:
2011/1/14 Chris Cappuccio ch...@nmedia.net:
nsd is already part of the tree and unbound will join it at some point
to
replace bind. B they are well documented, fairly easy to
BIND10 will be written in a combination of Python and C++, not really a
suitable upgrade for OpenBSD's base resolver/nameserver.
Not sure how long BIND9 is going to be maintained by ISC.
-Bryan.
Has anyone had any luck configuring the bind included with 4.7 (named
-v indicates it is 9.4.2-p2) as a DNSSEC validating resolver? Some
digging around the web indicates it might be to old to handle this
properly. If so is the version included with 4.8 any newer?
Thanks,
Josh Smith
KD8HRX
email
indicates it is 9.4.2-p2) as a DNSSEC validating resolver? Some
digging around the web indicates it might be to old to handle this
properly. If so is the version included with 4.8 any newer?
Thanks,
Josh Smith
KD8HRX
email/jabber:B juice...@gmail.com
phone:B 304.237.9369(c)
--
Let
29 matches
Mail list logo