Re: "Recursive no;" implications?
On 22 January 2014 05:29, LuKreme wrote:
> OK, so in order to lock down your server agains DDOS DNS attacks you need to
> restrict the access to the recursive lookup, yes? But if you set 'recursion
> no;' then your own servers will not lookup IP addresses for, for example, you
> mail server to check reject_unknown_reverse_client_hostname or related.
> Looking at that, if I am reading it correctly, I should have
> allow-recursion { "localnets"; }
So yes that is an option to restrict which IPs can perform recursion
by using an ACL. A better option (and better overall design) would be
to split your DNS servers, leave the current DNS servers as
authoritative only and install a second set of DNS servers as a
caching layer allowing recursion and do not have any direct inbound
access from the Internet. All internal clients point to the caching
layer.
> in the options on the master and slave DNS servers (along with any other
> specific IPs that I want to/need to allow). Given the risks in allowing
> recursion for the wilds of the Internet, how are companies like Google able
> to allow access to 8.8.8.8 and 8.8.4.4 without being used for these DDOS
> attacks?
Well they probably are being subjected to DDoS all the time, but
Google uses their own DNS implementation so more than likely they have
written in functionality to rate-limit and block specific
clients/requests. They also have a lot of bandwidth and they have a
lot of servers, using Anycast for distribution.
http://en.wikipedia.org/wiki/Google_Public_DNS
___
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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Jan 21, 2014, at 11:38 PM, LuKreme wrote: > > On 18 Jan 2014, at 06:52 , Larry Stone wrote: > >> That is not the problem. > > In the launchd plist do you have something like > > > NetworkState > > > > or maybe > > inetdCompatibility > > Wait > > > > to tell the system not to start bind until after the network is up? No, but neither does Apple. My launched plist is the same as what Apple provided with OS X 10.8 as well as being the one at http://opensource.apple.com/source/bind9/bind9-45.100/org.isc.named.plist modified only for the slightly different file specs. Note that per the launchd.plist man page, NetworkState is an option to the KeepAlive key and does not stand alone in a plist. http://www.apple.com/DTDs/PropertyList-1.0.dtd";> Disabled EnableTransactions Label org.isc.named OnDemand ProgramArguments /usr/local/sbin/named -f -c /usr/local/etc/named.conf ServiceIPC But another good area for experimentation when I have a chance (yesterday’s surprise announcement that Logmein is discontinuing their Free product effective immediately shuffled the priorities :-( ). -- Larry Stone lston...@stonejongleux.com http://www.stonejongleux.com/ 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: "Recursive no;" implications?
On Jan 22, 2014, at 3:43 AM, Steven Carr wrote: > On 22 January 2014 05:29, LuKreme wrote: >> in the options on the master and slave DNS servers (along with any other >> specific IPs that I want to/need to allow). Given the risks in allowing >> recursion for the wilds of the Internet, how are companies like Google able >> to allow access to 8.8.8.8 and 8.8.4.4 without being used for these DDOS >> attacks? > > Well they probably are being subjected to DDoS all the time, but > Google uses their own DNS implementation so more than likely they have > written in functionality to rate-limit and block specific > clients/requests. They also have a lot of bandwidth and they have a > lot of servers, using Anycast for distribution. > http://en.wikipedia.org/wiki/Google_Public_DNS In addition to being rate-limited, blocking, etc., I'm sure the Google servers are instrumented as data collection devices and are providing data back to someone regarding what DNS is actually doing and being used for. Why else would they do it? 8-) AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: "Recursive no;" implications?
Alan Clegg wrote: > >In addition to being rate-limited, blocking, etc., I'm sure the Google >servers are instrumented as data collection devices and are providing >data back to someone regarding what DNS is actually doing and being >used for. > >Why else would they do it? 8-) > >AlanC Google have argued that good, fast and reliable dns is a needed service. I know from experience that, sadly, many isps under provision their recursive resolvers and most people can't run their own (the "resolvers" in most CPE being a bad joke). So a 3rd party is a logical solution. I'm sure the data mining is an added benefit however... -- Sent from my phone with, please excuse brevity and typos ___ 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: "Recursive no;" implications?
In article , Phil Mayers wrote: > Alan Clegg wrote: > > > >In addition to being rate-limited, blocking, etc., I'm sure the Google > >servers are instrumented as data collection devices and are providing > >data back to someone regarding what DNS is actually doing and being > >used for. > > > >Why else would they do it? 8-) > > > >AlanC > > Google have argued that good, fast and reliable dns is a needed service. I > know from experience that, sadly, many isps under provision their recursive > resolvers and most people can't run their own (the "resolvers" in most CPE > being a bad joke). So a 3rd party is a logical solution. > > I'm sure the data mining is an added benefit however... Similar to why they're building their own fiber networks. If they make the infrastructure better, they expect to get more usage of their value-added services. -- Barry Margolin Arlington, MA ___ 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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On 22 Jan 2014, at 05:37 , Larry Stone wrote: > > On Jan 21, 2014, at 11:38 PM, LuKreme wrote: > >> >> On 18 Jan 2014, at 06:52 , Larry Stone wrote: >> >>> That is not the problem. >> >> In the launchd plist do you have something like >> >> >> NetworkState >> >> >> >> or maybe >> >> inetdCompatibility >> >> Wait >> >> >> >> to tell the system not to start bind until after the network is up? > > No, but neither does Apple. Right, but Apple did this by having their compile of bind start listening on 127.0.0.1 and then prodding it once the network was up and the IP address was available. Since Apple doesn't take this extra step, you'd need to tell launchd to wait for the Network, or you'd have to duplicate Apple's solution (probably by sending need a SIGHUP when the network is live). > My launched plist is the same as what Apple provided with OS X 10.8 Right, but bind was included with the base OS X client in 10.8. > But another good area for experimentation when I have a chance (yesterday’s > surprise announcement that Logmein is discontinuing their Free product > effective immediately shuffled the priorities :-( ). Yes, that rather pissed me off as well. It's one thing to discontinue a free service, it is something else entirely to cut it off with no warning. Oh well. -- 'Winners never talk about glorious victories. That's because they're the ones who see what the battlefield looks like afterwards. It's only the losers who have glorious victories.' --Small Gods ___ 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: "Recursive no;" implications?
On 22 Jan 2014, at 01:43 , Steven Carr wrote: > A better option (and better overall design) would be > to split your DNS servers, leave the current DNS servers as > authoritative only and install a second set of DNS servers as a > caching layer allowing recursion and do not have any direct inbound > access from the Internet. All internal clients point to the caching > layer. Ah, well, that's an idea. I could even run the caching dns on the nail server. -- And I'm nor insane, my mother had me tested. ___ 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: "Recursive no;" implications?
On 2014-01-22 00:43, Steven Carr wrote: Well they probably are being subjected to DDoS all the time, but Google uses their own DNS implementation so more than likely they have written in functionality to rate-limit and block specific clients/requests. They also have a lot of bandwidth and they have a lot of servers, using Anycast for distribution. http://en.wikipedia.org/wiki/Google_Public_DNS The fact that they're using anycast possibly helps their code detect DDoS attempts too; if their anycast farm in India receives a request "from" an IP in the US with half a dozen closer anycast farms/points, it can potentially assume that that query is part of an attack and rate limit much more drastically than is normally done. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren The cigarette does the smoking, you're just the sucker. ___ 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: Non-responsive name servers when started during boot on OS X Mavericks 10.9
On Wed, 22 Jan 2014, LuKreme wrote: Right, but Apple did this by having their compile of bind start listening on 127.0.0.1 and then prodding it once the network was up and the IP address was available. Since Apple doesn't take this extra step, you'd need to tell launchd to wait for the Network, or you'd have to duplicate Apple's solution (probably by sending need a SIGHUP when the network is live). This discussion is going full circle (although part of it may have been a couple of private emails I was sent). I speculated that Apple was making undocumented patches to bind and someone said no, it's as distributed. But this is why I really like installing from source - too many packagers making undocumented changes that cause software to behave differently than the documentation says it till. But I will get to testing your ideas. In the meantime, with a startup delay script and an hourly monitoring job, I have a "comfortable" environment. -- Larry Stone lston...@stonejongleux.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: Upgrading from 9.8.3 to 9.9.4
Thanks for that. I just remembered there was also the change to the db file having a default raw format on slaves unless specified. -Original Message- From: Lawrence K. Chen, P.Eng. [mailto:lkc...@ksu.edu] Sent: Tuesday, January 21, 2014 1:56 PM To: bind-users@lists.isc.org Subject: Re: Upgrading from 9.8.3 to 9.9.4 On 01/16/14 16:39, Mike Hoskins (michoski) wrote: > -Original Message- > From: Mike Bernhardt > Date: Thursday, January 16, 2014 4:09 PM > To: "bind-users@lists.isc.org" > Subject: RE: Upgrading from 9.8.3 to 9.9.4 > >> Sorry for the double post, but I forgot to ask this: >> And if it is indeed enabled regardless of my RFC1918 ranges, I would >> imagine that for my internal servers which have those ranges, I would >> want to add "disable-empty-zone ".";" to my global options? And for >> my external-facing server which of course has no RFC1918, I would >> leave it to the default setting? > > > You don't have to do this. BIND won't enable the empty zone if you > already have it defined. > > The problem I was referring to is mentioned in the feedback to this KB article: https://kb.isc.org/article/AA-00803/0/Why-are-queries-for-some-PTR-records-n o-longer-forwarded-since-upgrading-to-BIND-9.9.0.html Though, from 9.9.4 Release Notes, that's probably addressed by this bug fix: Fix forwarding for forward only "zones" beneath automatic empty zones. [RT #34583] -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally ___ 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: Upgrading from 9.8.3 to 9.9.4
-Original Message- From: Mike Bernhardt Date: Wednesday, January 22, 2014 at 3:25 PM To: "'Lawrence K. Chen, P.Eng.'" , "bind-users@lists.isc.org" Subject: RE: Upgrading from 9.8.3 to 9.9.4 >Thanks for that. I just remembered there was also the change to the db >file >having a default raw format on slaves unless specified. That's what I meant by my response about masterfile-format. :-) ___ 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
