DNS_RRL_MAX_RATE defines 1000

Zhiyong Cheng chengzhycn at gmail.com
Fri Jul 10 12:15:31 UTC 2020


在 2020年7月10日 +0800 AM2:11,Tony Finch <dot at dotat.at>,写道:
> Zhiyong Cheng <chengzhycn at gmail.com> wrote:
> >
> > We are using named cluster in our internal network as the authoritative
> > DNS. So there are no cache servers between clients and named cluster.
> > Maybe we should add one but it is just another story.
>
> Sorry, I wasn't completely clear: I was not saying that your authoritative
> servers should have a cache. I was saying that all the legitimate clients
> of your servers (the resolvers at ISPs areound the Internet) have caches.
>
All of these authoritative servers are only serve for our private clients. So
there won't have ISPs' resolvers.

I read the Bv9ARM again and noticed a hint in it:

 This mechanism is intended for authoritative DNS servers. It can be used on
 ecursive servers but can slow applications such as SMTP servers (mail
 receivers) and HTTP clients (web browsers) that repeatedly request the same
 domains. When possible, closing "open" recursive servers is better.

So it implies that I just should not use RRL in my authoritative servers.
Because all clients in my IDC internal queries my authoritative servers
directly. But RRL is not for this scenes.
> > To my mind the RRL should not limit queries with different qnames from
> > the same client. So is it my misunderstanding or wrong config?
>
> If you are querying for nonexistent names then RRL will treat the NXDOMAIN
> responses as equivalent, so it will rate-limit them. RRL limits responses,
> not queries. You can configure a different `nxdomains-per-second` limit if
> you want.

That’s it!  All of my queries are treated as equivalent. Thanks for your
patience :)
>
> Tony.
> --
> f.anthony.n.finch <dot at dotat.at> http://dotat.at/
> Rockall, Malin: Northwest 4 or 5. Moderate. Showers. Good.

Zhiyong Cheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200710/73df6ff0/attachment.htm>


More information about the bind-users mailing list