rate limit dns query response ...

prakash prakash at nic.in
Thu Apr 4 06:55:33 UTC 2013


  
Hello,
 
We are using bind 9.x on linux and would like to create rate limit for DNS 
query from any users ie 10 query per second. Can anyone guide us ....
 
Thanks & regards
Prakash Chand
Delhi


----- Original Message -----
From: bind-users-request at lists.isc.org
Date: Thursday, April 4, 2013 4:45 am
Subject: bind-users Digest, Vol 1487, Issue 2
To: bind-users at lists.isc.org

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


More information about the bind-users mailing list