Re: DNSSEC validating resolver
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 due to the protocol overhead not appropriate for larger networks / many clients. people keep claiming this bullshit. remains bullshit. The more I think about it... The only tcp connection you establish is from the host in question (i.e. workstation) to the resolver. The resolver then decides how to query the authoritative nameserver (udp/tcp), right? Aye? almost. it'll be more than one. that could be circumvented by a small local daemon, but that has other downsides. after all, the cost of establishing a tcp session isn't all that high, especially to the caching resolver which should be near aka low ttl. i even doubt it'd make much of a difference for a caching resolver. tcp sessions to the root servers and the common tld servers should stay established. dito for very commonly used other nameservers. the rest, yes, there is a little higher overhead. does it matter? i doubt it. but i have no numbers either. and thus, when i talk about the matter, i make clear this is an educated guess, no more, no less. Speaking about educated guesses, I personally have doubts about recommending the use of tcp only in the resolver, due to misconfigurations out there in the wild. I've seen cases where TCP access to port 53 have been blocked, both on the resolver and the server side, due no doubt to ignorance. That means, almost everything works almost all of the time, until someone tries a zone transfer, gets a large query result or comes along with a tcp only request. Indeed, the RFC:s have previously stated that implementing TCP is a should, not a must, which the good folks at IETF just recently seem to have put their foot down on: http://datatracker.ietf.org/doc/rfc5966/ So I guess my reservations will eventually end up being obsolete, but for the time being, I'd just stay on the safe side and continue allowing UDP. Regards, /Benny -- internetlabbet.se / work: +46 8 551 124 80 / Words must Benny Lvfgren/ mobile: +46 70 718 11 90 / be weighed, / fax:+46 8 551 124 89/not counted. /email: benny -at- internetlabbet.se
Re: DNSSEC validating resolver
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 /tounge in cheek flame Actually there is much debate about how much security dnssec adds, atleast currently. OpenSSL even, has had it's bugs. It is clear however that it makes Denial Of Service attacks much easier. The tcp resolv.conf option (quite possibly unique to OpenBSD) can already add much security to your resolving too. I imagine DNSSEC has very little to do with the unbound import. 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. I am certainly not saying don't use DNSSEC but you need to bear in mind the consequences. DNSSEC was known to need revising when it was rolled out, but I believe was implemented to give it many kicks in the direction of getting it right as throwing millions of dollars at it, wasn't ironing much out. Any axe murderer's out there? ;-) DNS looks trivial in the first place but it isn't. Please keep in mind that DNS is hidden in almost all common network services so you want to make and keep your DNS queries and responses as secure as possible.
Re: DNSSEC validating resolver
* 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, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: DNSSEC validating resolver
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. people keep claiming this bullshit. remains bullshit. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting 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. Thanks, Josh -- Josh Smith KD8HRX email/jabber: juice...@gmail.com phone: 304.237.9369(c)
Re: DNSSEC validating resolver
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 keep claiming this bullshit. remains bullshit. The more I think about it... The only tcp connection you establish is from the host in question (i.e. workstation) to the resolver. The resolver then decides how to query the authoritative nameserver (udp/tcp), right? Aye?
Re: DNSSEC validating resolver
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 overhead not appropriate for larger networks / many clients. people keep claiming this bullshit. remains bullshit. 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. resolv.conf has nothing to do with the resolver daemons behaviour. You can configure your network's resolver (bind, unbound, etc) to use TCP only.
Re: DNSSEC validating resolver
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 communication between client and recursive resolver. Well, in principle at least. -- Christian naddy Weisgerber na...@mips.inka.de
Re: DNSSEC validating resolver
* 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 appropriate for larger networks / many clients. people keep claiming this bullshit. remains bullshit. The more I think about it... The only tcp connection you establish is from the host in question (i.e. workstation) to the resolver. The resolver then decides how to query the authoritative nameserver (udp/tcp), right? Aye? almost. it'll be more than one. that could be circumvented by a small local daemon, but that has other downsides. after all, the cost of establishing a tcp session isn't all that high, especially to the caching resolver which should be near aka low ttl. i even doubt it'd make much of a difference for a caching resolver. tcp sessions to the root servers and the common tld servers should stay established. dito for very commonly used other nameservers. the rest, yes, there is a little higher overhead. does it matter? i doubt it. but i have no numbers either. and thus, when i talk about the matter, i make clear this is an educated guess, no more, no less. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: DNSSEC validating resolver
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 do a whole lot to protect the openbsd clients either. If bad people are injecting packets into your local network from the outside, you are boned. Get a new firewall. If bad people are injecting packets from the inside, you are double boned. Get a new network. Beyond that, the more common attack point for DNS is between the local recursive/caching server and the rest of the internet. Just because you trust the connection from workstation to server doesn't mean the data the server collected from the tubes at large is safe. You are securing the wrong part of the connection. 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.
Re: DNSSEC validating resolver
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, right? or was is left?
Re: DNSSEC validating resolver
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 included with 4.8 any newer? http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bind/version?rev=1.13;only_with_tag=OPENBSD_4_8_BASE jirib
Re: DNSSEC validating resolver
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 flame Actually there is much debate about how much security dnssec adds, atleast currently. OpenSSL even, has had it's bugs. It is clear however that it makes Denial Of Service attacks much easier. The tcp resolv.conf option (quite possibly unique to OpenBSD) can already add much security to your resolving too. I imagine DNSSEC has very little to do with the unbound import. I am certainly not saying don't use DNSSEC but you need to bear in mind the consequences. DNSSEC was known to need revising when it was rolled out, but I believe was implemented to give it many kicks in the direction of getting it right as throwing millions of dollars at it, wasn't ironing much out. Any axe murderer's out there? ;-) Debate indeed; it potentially creates new problems. See here (http://dnscurve.org/nsec3walker.html) and here (http://dnscurve.org/amplification.html) for examples. It's Dan Bernstein's writing, so it's definitely an alternate viewpoint :) But what he says is interesting on paper, though his scheme could end up the Betamax to DNSSEC's VHS. Corey
Re: DNSSEC validating resolver
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 alternate viewpoint :) B But what he says is interesting on paper, though his scheme could end up the Betamax to DNSSEC's VHS. Corey I agree there is room for debate on which is a better approach (dnscurve or dnssec) however dnssec seems to have the wider adoption as of now and I would like to support it and I thank everyone for the suggestions of using unbound from ports. Thanks, -- Josh Smith KD8HRX email/jabber: juice...@gmail.com phone: 304.237.9369(c)
Re: DNSSEC validating resolver
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 much security dnssec adds, atleast currently. OpenSSL even, has had it's bugs. It is clear however that it makes Denial Of Service attacks much easier. The tcp resolv.conf option (quite possibly unique to OpenBSD) can already add much security to your resolving too. I imagine DNSSEC has very little to do with the unbound import. I am certainly not saying don't use DNSSEC but you need to bear in mind the consequences. DNSSEC was known to need revising when it was rolled out, but I believe was implemented to give it many kicks in the direction of getting it right as throwing millions of dollars at it, wasn't ironing much out. Any axe murderer's out there? ;-)
Re: DNSSEC validating resolver
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 that command. Or better re-phrase the question: Why did ISC make it so complicated to import the latest stable release of their nameserver software into OpenBSD base?
Re: DNSSEC validating resolver
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 you are that smart to use DNSSEC, then you should also be that smart to run that command. Or better re-phrase the question: B Why did ISC make it so complicated to import the latest stable B release of their nameserver software into OpenBSD base? Oliver, I suppose my tongue in cheek flame tags or my statement them didn't make it obvious enough but that comment was meant to be completely facetious and just a joke... I apologize if I offended you with my (poor??) attempt at humor? Thanks, Josh Smith KD8HRX email/jabber:B juice...@gmail.com phone:B 304.237.9369(c)
Re: DNSSEC validating resolver
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)
Re: DNSSEC validating resolver
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 included with 4.8 any newer? Are you talking about a recursive resolver (caching dns server) or the resolver used internally (i.e. the thing which reads resolv.conf and resolves names for most parts of the OS)? There is work in progress for the former (by moving to unbound, as noted in other replies) but not afaik the latter.
Re: DNSSEC validating resolver
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 DNSSSEC validiating resolver should be in base, not ports. Sure, but integrating this takes time and a lot of work. Using unbound from ports is perfectly workable in the interim.
Re: DNSSEC validating resolver
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 indicates it might be to old to handle this properly. B If so is the version included with 4.8 any newer? Are you talking about a recursive resolver (caching dns server) or the resolver used internally (i.e. the thing which reads resolv.conf and resolves names for most parts of the OS)? Stuart, I am talking about a caching dns server. I apologize for not being clear earlier. I guess I'll take a look at unbound from ports since that seems to be what everyone is suggesting. 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 After reading the issues regarding the inclusion of bind 10 in base. I completely understand the devs decision to move to another dns server. Thanks, Josh snip -- Josh Smith KD8HRX email/jabber: juice...@gmail.com phone: 304.237.9369(c)
Re: DNSSEC validating resolver
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
Re: DNSSEC validating resolver
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. Best Martin
Re: DNSSEC validating resolver
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 easy to use, and unbound is available through ports. use it. But a DNSSSEC validiating resolver should be in base, not ports. Instead of bitching you could start yourself and send some patches or ask the guy who imported NSD about the status and his hints. j.
Re: DNSSEC validating resolver
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 validiating resolver should be in base, not ports. From what I've heard that's already the plan: http://old.nabble.com/Re:-Testing-NSD-p29509010.html
Re: DNSSEC validating resolver
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 nsd/unbound will be replacing bind in base? Thanks, Josh Smith KD8HRX email/jabber: juice...@gmail.com phone: 304.237.9369(c) snip
Re: DNSSEC validating resolver
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 use, and unbound is available through ports. use it. But a DNSSSEC validiating resolver should be in base, not ports. From what I've heard that's already the plan: B B B B http://old.nabble.com/Re:-Testing-NSD-p29509010.html Looks like peter answered my question before I asked it :-) -- Josh Smith KD8HRX email/jabber: juice...@gmail.com phone: 304.237.9369(c)
Re: DNSSEC validating resolver
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.
DNSSEC validating resolver
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/jabber:B juice...@gmail.com phone:B 304.237.9369(c)
Re: DNSSEC validating resolver
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. 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 included with 4.8 any newer? Thanks, Josh Smith KD8HRX email/jabber:B juice...@gmail.com phone:B 304.237.9369(c) -- Let food be thy medicine and medicine be thy food - Hippocrates
