Re: Disabling rate-limit?
On Mon, Aug 15, 2016 at 11:23 PM, blrmaani wrote: > From tcpdump, it appears that customers are receiving delayed response and > are too sensitive for timeouts. > > The queries they are sending are authoritative i.e the zone is on our > nameserver. > > How do I trouble-shoot this issue? This is really intermittent and hard to > reproduce.. I'm a little confused: if your clients are _sending_ queries, they're either sending recursive queries, or they're acting as nameservers themselves and are sending iterative queries, following delegation to resolve names outside of your domain. If your clients are _replying_ to queries, then they are acting as authoritative nameservers--answering queries for records in your domain. To dig into things further, nameserver logs and errors would be helpful, as would your config. You might also consider doing a selective packet capture on your nameservers for the clients that are having problems. If you haven't already, I highly recommend picking up a copy of Albitz and Liu's _DNS_and_BIND_: it's a bit dated, but still a good introduction to the basics of BIND. John ___ 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: Re: Disabling rate-limit?
Blr,
We do run RRL on some of our servers, example option clause below that
activates the feature. Two suggestions:
1. You mention you 'inherited' the server and looked at /etc/named.conf --
verify that it is not running chroot to another directory and using another
config file (I know it's obvious, but I've been caught several times by this).
2. I might agree with some of the other responses that think the logging you
are seeing is NOT from RRL. Logging/options from a server running 9.9.8
below. You can see the lines are tagged with 'rate-limit' :
30-Jul-2016 22:08:12.185 rate-limit: info: stop limiting error responses to
12.109.112.112/28
30-Jul-2016 23:21:07.296 rate-limit: info: limit NXDOMAIN responses to
65.218.138.48/28 for 168.192.IN-ADDR.ARPA (05bd036f)
30-Jul-2016 23:21:07.296 rate-limit: info: client 65.218.138.57#48702
(153.12.168.192.in-addr.arpa): rate limit slip NXDOMAIN response to
65.218.138.48/28 for 168.192.IN-ADDR.ARPA (05bd036f)
rate-limit {
domain ".";
responses-per-second50;
window 15;
log-onlyno;
qps-scale 35000;
IPv4-prefix-length 28;
IPv6-prefix-length 56;
slip2;
exempt-clients { 127.0.0.1/32; ... }
}
John
--
Message: 6
Date: Mon, 15 Aug 2016 20:23:17 -0700 (PDT)
From: blrmaani
To: comp-protocols-dns-b...@isc.org
Subject: Re: Disabling rate-limit?
Message-ID:
Content-Type: text/plain; charset=UTF-8
>From tcpdump, it appears that customers are receiving delayed response and are
>too sensitive for timeouts.
The queries they are sending are authoritative i.e the zone is on our
nameserver.
How do I trouble-shoot this issue? This is really intermittent and hard to
reproduce..
thanks
Blr
On Monday, August 15, 2016 at 7:27:44 PM UTC-7, John Miller wrote:
> Hi Blr,
>
> First things first: if your customers are sending queries, this is
> probably about their own recursive queries timing out, rather than
> incoming authoritative queries timing out.
>
> Something else you should check: are your customers receiving a
> delayed (say a few seconds) SERVFAIL response, or are they receiving
> no response at all?
>
> There's a different set of options in BIND for recursive rate limiting
> versus authoritative rate limiting.
>
> Recursive queries:
>
> * recursive-clients
> * clients-per-query
> * max-clients-per-query
>
> Running 'rndc status' is a good way to see how close you are to these
> limits; you'll see log messages like
>
> "no more recursive clients: quota reached"
>
> There's also a newer set of "recursive client rate-limiting" features
> available in newer (9.9 and 9.10) versions of BIND, but I'm pretty
> sure this doesn't apply to your case.
>
> Authoritative queries:
> https://kb.isc.org/article/AA-00994/0/Using-the-Response-Rate-Limiting-Feature-in-BIND-9.10.html
> IIRC, rate-limiting for authoritative queries (called "Response rate
> limiting" or "RRL") wasn't enabled by default until BIND 9.10.x, and
> required a specific build in BIND 9.9.x. It's not available in BIND
> 9.8.x.
>
> John
>
> On Mon, Aug 15, 2016 at 9:22 PM, blrmaani wrote:
> > I inherited a DNS server which is running BIND 9.8.x. There was a DNS
> > incident where our customers complained that they saw query timeouts
> > intermittently (Our customers run cassandra/hadoop applications and send
> > same queries repeatedly). They also run nscd on their hosts but I was told
> > all have same TTL value of 3600 indicating all names expire at the same
> > time on thousands of client hosts).
> >
> > I tried to reproduce the issue by sending hostname.bind queries and I see
> > logs similar to the one below:
> >
> > named[]: limit responses to for
> > hostname.bind CH TXT
> > named[]: *stop limiting responses to
> > for hostname.bind CH TXT
> >
> >
> > I reviewed /etc/named.conf and do not see 'rate-limit' configuration. I am
> > confused because BIND ARM says rate-limit is disabled by default. But logs
> > indicate otherwise.
> >
> > ( I did "grep rate /etc/*" and didn't see anything. There are no includes
> > in named.conf)
> >
> > Please advice on how I can disable rate-limit on my DNS server.
> >
> >
> > I did a strings on 'named' binary and see this:
> >
> > strings /usr/sbin/named | egrep -i rrl
> > dns_rrl
> > dns_rrl_init
> > dns_rrl_view_destroy
> >
> > What else do I need to check to identify if RRL is enabled?
> >
> >
> > Thanks
> > Blr
> > ___
> > 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
>
>
>
> --
> John Miller
> Systems Engineer
> Brandeis Universi
Re: Problem looking up domain dryfire.com
The nameservers are broken. They send back rcode 17 (which is yet
to be assigned) when they see a query with a EDNS option present
rather than ignore the option as required by RFC 6891. They also
send back RCODE 17 rather than BADVERS (16) when send a EDNS(1)
query. The servers also don't answer over TCP which is a third issue.
The operators should contact their nameserver vendor for a fix or
otherwise replace them.
EDNS compliance test results for dryfire.com can be found at
https://ednscomp.isc.org/ednscomp/210f3a1e3e
You can work around this in the short term by adding server clauses
for the servers to tell named to not send EDNS COOKIES to them.
This of course does not scale.
server { request-sit no; };9.10.x
servet { send-cookie no; };9.11.0 onwards
Mark
; <<>> DiG 9.11.0b3 <<>> +dnssec dryfire.com ns @213.162.97.178
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: ?17, id: 29228
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; Query time: 440 msec
;; SERVER: 213.162.97.178#53(213.162.97.178)
;; WHEN: Tue Aug 16 20:58:42 EST 2016
;; MSG SIZE rcvd: 23
; <<>> DiG 9.11.0b3 <<>> +dnssec dryfire.com ns @213.162.97.178 +nocookie
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49671
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dryfire.com. IN NS
;; ANSWER SECTION:
dryfire.com.21600 IN NS dns0.getsurfed.com.
dryfire.com.21600 IN NS dns1.getsurfed.com.
;; Query time: 367 msec
;; SERVER: 213.162.97.178#53(213.162.97.178)
;; WHEN: Tue Aug 16 20:59:37 EST 2016
;; MSG SIZE rcvd: 88
; <<>> DiG 9.11.0b3 <<>> +dnssec dryfire.com ns @213.162.97.178 +nocookie
+edns=1 +noednsneg
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: ?17, id: 8994
;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; Query time: 541 msec
;; SERVER: 213.162.97.178#53(213.162.97.178)
;; WHEN: Tue Aug 16 21:06:13 EST 2016
;; MSG SIZE rcvd: 23
In message <9634ef8af31f19965c5c3b2db3f98...@gluping.no>, Eivind Olsen writes:
> Hello.
>
> I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving
> getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for
> RHEL/CentOS/Fedora.
>
> I can do manual lookups of the domain with "dig" and point it to their
> servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if
> I go through my BIND installation.
>
> The named.run log contains lines like this:
>
> 16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE
> resolving 'dryfire.com/NS/IN': 213.162.97.178#53
> 16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE
> resolving 'dryfire.com/NS/IN': 213.162.97.177#53
>
> A search for "17 unexpected RCODE" seems to indicate this might be
> caused by incompatibility between SIT/DNS cookies and older versions of
> NSD. Is this also what's happening in my case here?
>
> Regards
> Eivind Olsen
> ___
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: Problem looking up domain dryfire.com
On Tue, Aug 16, 2016 at 11:04:14AM +0200, Eivind Olsen wrote: > Hello. > > I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving > getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for > RHEL/CentOS/Fedora. > > I can do manual lookups of the domain with "dig" and point it to their > servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if I go > through my BIND installation. > > The named.run log contains lines like this: > > 16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE resolving > 'dryfire.com/NS/IN': 213.162.97.178#53 > 16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE resolving > 'dryfire.com/NS/IN': 213.162.97.177#53 > > A search for "17 unexpected RCODE" seems to indicate this might be caused by > incompatibility between SIT/DNS cookies and older versions of NSD. Is this > also what's happening in my case here? Possibly: [muks@jurassic bind9]$ bin/dig +cookie @dns0.getsurfed.com. getsurfed.com. ; <<>> DiG 9.11.0a3 <<>> +cookie @dns0.getsurfed.com. getsurfed.com. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: ?17, id: 39495 ;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; Query time: 189 msec ;; SERVER: 213.162.97.177#53(213.162.97.177) ;; WHEN: Tue Aug 16 15:50:50 IST 2016 ;; MSG SIZE rcvd: 23 [muks@jurassic bind9]$ bin/dig +nocookie @dns0.getsurfed.com. getsurfed.com. ; <<>> DiG 9.11.0a3 <<>> +nocookie @dns0.getsurfed.com. getsurfed.com. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38178 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;getsurfed.com. IN A ;; ANSWER SECTION: getsurfed.com. 21600 IN A 213.162.97.82 ;; AUTHORITY SECTION: getsurfed.com. 21600 IN NS dns0.getsurfed.com. getsurfed.com. 21600 IN NS dns1.getsurfed.com. ;; ADDITIONAL SECTION: dns0.getsurfed.com. 3600IN A 213.162.97.177 dns1.getsurfed.com. 3600IN A 213.162.97.178 ;; Query time: 189 msec ;; SERVER: 213.162.97.177#53(213.162.97.177) ;; WHEN: Tue Aug 16 15:50:52 IST 2016 ;; MSG SIZE rcvd: 128 [muks@jurassic bind9]$ Mukund signature.asc Description: PGP 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
Problem looking up domain dryfire.com
Hello. I'm seeing some odd problems where BIND (9.10.4-P2) has issues resolving getsurfed.com. This is when using the "510 Software Group" BIND 9.10 for RHEL/CentOS/Fedora. I can do manual lookups of the domain with "dig" and point it to their servers (dns0.getsurfed.com, dns1.getsurfed.com) but it fails for me if I go through my BIND installation. The named.run log contains lines like this: 16-Aug-2016 10:48:40.693 lame-servers: info: 17 unexpected RCODE resolving 'dryfire.com/NS/IN': 213.162.97.178#53 16-Aug-2016 10:48:40.749 lame-servers: info: 17 unexpected RCODE resolving 'dryfire.com/NS/IN': 213.162.97.177#53 A search for "17 unexpected RCODE" seems to indicate this might be caused by incompatibility between SIT/DNS cookies and older versions of NSD. Is this also what's happening in my case here? Regards Eivind Olsen ___ 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: DNSKEY and RRSIG DNSKEY TTL values aren't changed after changing of zone's TTL
Thanks for a workaround. But in this case - after "dnssec-settime -L ttl" I
need unsign/sign zone (p.1 of steps above) in order to new TTL value
appeared in DNSKEY RRset ("service bind9 reload" or "rndc loadkeys" has no
effect). But I would like to find a solution without the need of
unsigning/signing cycle.
Besides, the question is: this is a bug? Or this behavior is caused by some
rules or restrictions?
С уважением,
Александр Остапенко
2016-08-16 8:59 GMT+07:00 Mark Andrews :
>
> In message mail.gmail.com>
> , =?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCe0YHRgtCw0L/QtdC90LrQvg==?= writes:
> > Hello.
> >
> > I'm using BIND 9.9.5.
> > My steps:
> >
> >1. Sign zone using one 1 ZSK and 2 KSK: a) adding "*auto-dnssec
> >maintain;*" and "*inline-signing yes;*" directive into zone section of
> >named.conf; b) setting publication and activation timestamps to
> current
> >time in key files; c) *rndc reload*.
> >2. Change TTL value in the zone file ($TTL 86400 ==> $TTL 432000).
> >3. Increase serial number in SOA record by 1.
> >4. *rndc reload*.
> >
> > After that - DNSKEY and RRSIG DNSKEY records still have 86400 value in
> TTL
> > (checked via *dig*).
> > What could be the reason for such behavior?
> >
> >
> > Kind regards,
> > Aleks Ostapenko
>
> Use "dnssec-settime -L ttl"
>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
>
___
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
