<DIV>Hello,</DIV>
<DIV> </DIV>
<DIV>We are using bind 9.x on linux and would like to create rate limit for DNS </DIV>
<DIV>query from any users ie 10 query per second. Can anyone guide us ....</DIV>
<DIV> </DIV>
<DIV>Thanks & regards</DIV>
<DIV>Prakash Chand</DIV>
<DIV>Delhi<BR><BR>----- Original Message -----<BR>From: bind-users-request@lists.isc.org<BR>Date: Thursday, April 4, 2013 4:45 am<BR>Subject: bind-users Digest, Vol 1487, Issue 2<BR>To: bind-users@lists.isc.org<BR><BR>> Send bind-users mailing list submissions to<BR>> bind-users@lists.isc.org<BR>> <BR>> To subscribe or unsubscribe via the World Wide Web, visit<BR>> https://lists.isc.org/mailman/listinfo/bind-users<BR>> or, via email, send a message with subject or body 'help' to<BR>> bind-users-request@lists.isc.org<BR>> <BR>> You can reach the person managing the list at<BR>> bind-users-owner@lists.isc.org<BR>> <BR>> When replying, please edit your Subject line so it is more specific<BR>> than "Re: Contents of bind-users digest..."<BR>> <BR>> <BR>> Today's Topics:<BR>> <BR>> 1. Re: RPZ and negative answers (Noel Butler)<BR>> 2. Re: Auto-dnssec maintain and 'continous' <BR>> resigning (Mark Andrews)<BR>> 3. Re: Blocking private addresses with a optionq <BR>> (Vernon Schryver)<BR>> 4. Re: is NS record pointing to "some other name <BR>> server" needed<BR>> in case of classless IN-ADDR.ARPA <BR>> delegations? (Mark Andrews)<BR>> 5. Re: DLZ $client% parameter segfault (Michael <BR>> McConnell) 6. Re: RPZ and negative answers (Vernon <BR>> Schryver)<BR>> <BR>> -----------------------------------------------------------------<BR>> -----<BR>> <BR>> Message: 1<BR>> Date: Thu, 04 Apr 2013 08:22:49 +1000<BR>> From: Noel Butler <noel.butler@ausics.net><BR>> To: bind-users@lists.isc.org<BR>> Subject: Re: RPZ and negative answers<BR>> Message-ID: <1365027769.3947.8.camel@tardis><BR>> Content-Type: text/plain; charset="utf-8"<BR>> <BR>> On Tue, 2013-04-02 at 14:16 -0700, Chris Buxton wrote:<BR>> <BR>> > Can anyone explain this to me?<BR>> > <BR>> > If a name exists in the response policy, and also exists in <BR>> the real Internet namespace, the value from the policy is <BR>> returned. But if it doesn't exist out on the Internet, then the <BR>> value is not returned -- an NXDOMAIN (or SERVFAIL, or whatever) <BR>> is returned instead.<BR>> > <BR>> > I've known this for a while but haven't understood why it is <BR>> thus. Today, it has become a problem for me. If I set a policy <BR>> of "this name gets response X", I expect that policy to be used <BR>> rather than "this name gets response X unless it doesn't exist <BR>> out on the Internet or can't be resolved due to an error."<BR>> > <BR>> <BR>> <BR>> Perhaps because it is a "response" zone, not an <BR>> actual authoritative<BR>> "zone"?<BR>> Sounds strange, but makes sense to me.<BR>> -------------- next part --------------<BR>> An HTML attachment was scrubbed...<BR>> URL: <https://lists.isc.org/pipermail/bind-<BR>> users/attachments/20130404/02153e74/attachment-0001.html><BR>> -------------- next part --------------<BR>> A non-text attachment was scrubbed...<BR>> Name: signature.asc<BR>> Type: application/pgp-signature<BR>> Size: 490 bytes<BR>> Desc: This is a digitally signed message part<BR>> URL: <https://lists.isc.org/pipermail/bind-<BR>> users/attachments/20130404/02153e74/attachment-0001.bin><BR>> <BR>> ------------------------------<BR>> <BR>> Message: 2<BR>> Date: Thu, 04 Apr 2013 09:48:30 +1100<BR>> From: Mark Andrews <marka@isc.org><BR>> To: Phil Mayers <p.mayers@imperial.ac.uk><BR>> Cc: bind-users@isc.org<BR>> Subject: Re: Auto-dnssec maintain and 'continous' resigning<BR>> Message-ID: <20130403224830.7D62631DF8FA@drugs.dv.isc.org><BR>> <BR>> <BR>> In message <515A92A5.3020302@imperial.ac.uk>, Phil Mayers writes:<BR>> > On 04/01/2013 07:36 PM, Carlos M. Martinez wrote:<BR>> > > Reframing the question in more general terms... Which events <BR>> trigger a<BR>> > > zone re-sign and reload when using "auto-dnssec maintain" ?<BR>> > <BR>> > As someone else has already said, zone updates, signature <BR>> expiration and <BR>> > key events.<BR>> > <BR>> > In particular, it's normal for the SOA serial to constantly <BR>> increase in <BR>> > a zone with "auto-dnssec maintain", even if nothing else <BR>> happens, <BR>> > because the signatures will be regenerated every N days. N <BR>> depends on <BR>> > your config, but is 0.75 * default_sig_life (30 days) by <BR>> default i.e. <BR>> > signatures are generated every 22.5 days.<BR>> <BR>> Named attempts to spread out re-signing load for a zone over time<BR>> even is the zone content is essentially static. It takes <BR>> time to<BR>> regenerate signatures so you don't want non-threaded builds to stall<BR>> too long res-signing.<BR>> <BR>> > _______________________________________________<BR>> > Please visit https://lists.isc.org/mailman/listinfo/bind-users <BR>> to unsubscribe<BR>> > from this list<BR>> > <BR>> > bind-users mailing list<BR>> > bind-users@lists.isc.org<BR>> > https://lists.isc.org/mailman/listinfo/bind-users<BR>> -- <BR>> Mark Andrews, ISC<BR>> 1 Seymour St., Dundas Valley, NSW 2117, Australia<BR>> PHONE: +61 2 9871 <BR>> 4742 INTERNET: marka@isc.org<BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 3<BR>> Date: Wed, 3 Apr 2013 22:56:23 GMT<BR>> From: Vernon Schryver <vjs@rhyolite.com><BR>> To: bind-users@lists.isc.org<BR>> Subject: Re: Blocking private addresses with a optionq<BR>> Message-ID: <201304032256.r33MuNVB064371@calcite.rhyolite.com><BR>> <BR>> > From: "Lawrence K. Chen, P.Eng." <lkchen@ksu.edu><BR>> <BR>> > First thing that got my attention was that "The rules encoded <BR>> in a<BR>> > response policy zone (RPZ) are applied only to responses to queries<BR>> > that ask for recursion". But, these are authoritative <BR>> only nameservers....<BR>> > So, would RPZ work in this case?<BR>> <BR>> This is some more complete text from the 9.8.4-P1 ARM without patches:<BR>> <BR>> By default, the actions encoded in an RPZ are <BR>> applied only to queries that ask for recursion <BR>> (RD=1). That default can be changed for a <BR>> single RPZ or all RPZs in a view<BR>> with a <command>recursive-only <BR>> no</command> clause.<BR>> <BR>> <BR>> Vernon Schryver vjs@rhyolite.com<BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 4<BR>> Date: Thu, 04 Apr 2013 10:03:33 +1100<BR>> From: Mark Andrews <marka@isc.org><BR>> To: Martin T <m4rtntns@gmail.com><BR>> Cc: bind-users@isc.org<BR>> Subject: Re: is NS record pointing to "some other name server" needed<BR>> in case of classless IN-ADDR.ARPA delegations?<BR>> Message-ID: <20130403230333.D905531DFB1A@drugs.dv.isc.org><BR>> <BR>> <BR>> If a zone is being made available to the public (which these are)<BR>> then steps should be taken to ensure it is resolvable all the time.<BR>> This means having multiple servers that are not subject to common<BR>> failures. This is basic DNS.<BR>> <BR>> In message <BR>> <CAJx5YvE43cTiNmw+AEun01pAig3kjK8D+4TBhVAwYhUiqgNt7g@mail.gmail.com>, Martin T writes:<BR>> > Hi,<BR>> > <BR>> > in case of classless IN-ADDR.ARPA<BR>> > delegations(http://www.ietf.org/rfc/rfc2317.txt) I have <BR>> usually seen<BR>> > at least one NS record pointing to name server other than the<BR>> > end-customer ones. Example from rfc2317.txt where there are <BR>> two NS<BR>> > records and the second one is not the end-customer name server:<BR>> > <BR>> > <BR>> > ; <<0-127>> /25<BR>> > <BR>> 0/25 NS ns.A.domain.<BR>> > <BR>> 0/25 NS some.other.name.server.<BR>> > ;<BR>> > <BR>> 1 CNAME 1.0/25.2.0.192.in-addr.arpa.<BR>> > <BR>> 2 CNAME 2.0/25.2.0.192.in-addr.arpa.<BR>> > <BR>> 3 CNAME 3.0/25.2.0.192.in-addr.arpa.<BR>> > ;<BR>> > <BR>> > <BR>> > Another example from one real name server zone file:<BR>> > <BR>> > ;<BR>> > <BR>> 0 IN NS ns.content-providerA.com.<BR>> > <BR>> 0 IN NS ns2.content-providerA.com.<BR>> > <BR>> 0 IN NS ns.isp-of-content-providerA.net.<BR>> > ;<BR>> > <BR>> 1 IN CNAME 1.0.47.168.192.in-addr.arpa.<BR>> > <BR>> 2 IN CNAME 2.0.47.168.192.in-addr.arpa.<BR>> > <BR>> 3 IN CNAME 3.0.47.168.192.in-addr.arpa.<BR>> > ;<BR>> > <BR>> > Is NS record pointing to "some other name server" needed in <BR>> case of<BR>> > classless IN-ADDR.ARPA delegations? What happens if one does not<BR>> > specify this?<BR>> > <BR>> > <BR>> > regards,<BR>> > Martin<BR>> > _______________________________________________<BR>> > Please visit https://lists.isc.org/mailman/listinfo/bind-users <BR>> to unsubscribe from this list<BR>> > <BR>> > bind-users mailing list<BR>> > bind-users@lists.isc.org<BR>> > https://lists.isc.org/mailman/listinfo/bind-users<BR>> -- <BR>> Mark Andrews, ISC<BR>> 1 Seymour St., Dundas Valley, NSW 2117, Australia<BR>> PHONE: +61 2 9871 <BR>> 4742 INTERNET: marka@isc.org<BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> Message: 5<BR>> Date: Wed, 3 Apr 2013 17:12:34 -0600<BR>> From: Michael McConnell <michael@winkstreaming.com><BR>> To: "Vadim S. Goncharov" <vgoncharov@nic.ru><BR>> Cc: bind-users@lists.isc.org<BR>> Subject: Re: DLZ $client% parameter segfault<BR>> Message-ID: <831DD514-A708-4B47-ADFA-<BR>> 578ABCB45100@winkstreaming.com>Content-Type: text/plain; <BR>> charset="windows-1252"<BR>> <BR>> Thanks certainly blows up the possibility of doing native GeoDNS <BR>> at the moment? Any chance I am overlooking a method which I <BR>> could effectively get the clients address into a MySQL query <BR>> with the current 9.9.2 release?<BR>> <BR>> Thanks again,<BR>> Michael<BR>> <BR>> --<BR>> <BR>> Michael McConnell<BR>> WINK Streaming;<BR>> email: michael@winkstreaming.com<BR>> phone: +1 312 281-5433 x 7400<BR>> cell: +506 8706-2389<BR>> skype: wink-michael<BR>> web: http://winkstreaming.com<BR>> <BR>> On Apr 2, 2013, at 4:03 AM, "Vadim S. Goncharov" <BR>> <vgoncharov@nic.ru> wrote:<BR>> <BR>> > On 02.04.2013 01:13, Michael McConnell wrote:<BR>> > <BR>> > Unfortunatelly, $client$ is only supported in allowzonexfr() <BR>> method (see e.g. http://bind-<BR>> dlz.sourceforge.net/mysql_driver.html for some info about SDLZ <BR>> methods). It would be nice to have it in others, too, but BIND <BR>> does not pass it via current API, alas.<BR>> > <BR>> > In all others 'client' struct member just becomes NULL, so <BR>> leads to segfault (yes, that's a bug).<BR>> > <BR>> >> The $client$ parameter appears to work for zone transfers, as <BR>> per this<BR>> >> example https://github.com/opennetadmin/ona/wiki/bind-dlz<BR>> >> However if I use $client$ on any other queries bind segfaults.<BR>> >> <BR>> >> Strace doesn't seem to show anything useful...<BR>> >> <BR>> >> Ideas?<BR>> >> <BR>> >> Thanks again,<BR>> >> Mike<BR>> >> <BR>> >> On Apr 1, 2013, at 2:51 PM, Michael McConnell <BR>> <michael@winkstreaming.com>> <BR>> <mailto:michael@winkstreaming.com>> wrote:<BR>> >> <BR>> >>> Hello All,<BR>> >>> <BR>> >>> I am trying to use Bind 9.9.2-P2 with the DLZ module, <BR>> however I continue<BR>> >>> to run into segfault issues when trying to use $client$<BR>> >>> <BR>> >>> {SELECT SQL_CACHE zone_name FROM dns_zones ? }<BR>> >>> {{select zone_ttl AS ttl ?. WHERE geo_ip LIKE '$client$'}<BR>> >>> <BR>> >>> I am trying to user $client$ in the A record lookup, not the zone<BR>> >>> transfer. Is this possible?<BR>> >>> <BR>> >>> Thanks so much,<BR>> >>> Michael<BR>> > <BR>> > <BR>> > -- <BR>> > Vadim Goncharov <BR>> <vgoncharov@nic.ru> RU-Center<BR>> > NET <BR>> Department http://www.nic.ru<BR>> > NET-SYS <BR>> Group phone:+7(495)737-7646 (ext.4019)<BR>> > _______________________________________________<BR>> > Please visit https://lists.isc.org/mailman/listinfo/bind-users <BR>> to unsubscribe from this list<BR>> > <BR>> > bind-users mailing list<BR>> > bind-users@lists.isc.org<BR>> > https://lists.isc.org/mailman/listinfo/bind-users<BR>> <BR>> -------------- next part --------------<BR>> An HTML attachment was scrubbed...<BR>> URL: <https://lists.isc.org/pipermail/bind-<BR>> users/attachments/20130403/5b6686cc/attachment-0001.html><BR>> <BR>> ------------------------------<BR>> <BR>> Message: 6<BR>> Date: Wed, 3 Apr 2013 23:13:27 GMT<BR>> From: Vernon Schryver <vjs@rhyolite.com><BR>> To: bind-users@lists.isc.org<BR>> Subject: Re: RPZ and negative answers<BR>> Message-ID: <201304032313.r33NDR3g014467@calcite.rhyolite.com><BR>> <BR>> > From: Chris Buxton <clists@buxtonfamily.us><BR>> <BR>> > If a name exists in the response policy, and also exists in <BR>> the real<BR>> > Internet namespace, the value from the policy is returned. But <BR>> if it<BR>> > doesn't exist out on the Internet, then the value is not <BR>> returned --<BR>> > an NXDOMAIN (or SERVFAIL, or whatever) is returned instead.<BR>> ><BR>> > I've known this for a while but haven't understood why it is thus.<BR>> > Today, it has become a problem for me. If I set a policy of "this<BR>> > name gets response X", I expect that policy to be used rather than<BR>> > "this name gets response X unless it doesn't exist out on the<BR>> > Internet or can't be resolved due to an error."<BR>> <BR>> RPZ stands for "response policy zone" and concerns rewriting responses<BR>> instead of queries. The answer section of an NXDOMAIN or <BR>> SERFVAILresponse does not contain a domain name that could <BR>> trigger rewriting.<BR>> <BR>> Rewriting queries instead of responses would fail to rewrite CNAME<BR>> chains.<BR>> <BR>> Even when the unrewritten response is an error such as NXDOMAIN, an<BR>> RPZ action can be triggered by the name or address of any NS RR that<BR>> is authoritative for the response and that is found in glue or <BR>> otherwise.<BR>> Previous versions of the RPZ mechanism in BIND required ./configure<BR>> settings to enable rpz-nsip and rpz-nsdname rules. They <BR>> are enabled<BR>> by default in future released versions of BIND as well as the <BR>> speed-up<BR>> patches that can found by following the link labeled <BR>> "Patch files for<BR>> BIND9" on http://www.redbarn.org/dns/ratelimits<BR>> <BR>> <BR>> Vernon Schryver vjs@rhyolite.com<BR>> <BR>> <BR>> ------------------------------<BR>> <BR>> _______________________________________________<BR>> bind-users mailing list<BR>> bind-users@lists.isc.org<BR>> https://lists.isc.org/mailman/listinfo/bind-users<BR>> <BR>> End of bind-users Digest, Vol 1487, Issue 2<BR>> *******************************************</DIV>