caching does not seem to be working for internal view
Robert Moskowitz
rgm at htt-consult.com
Wed Aug 3 18:43:48 UTC 2022
Perhaps this is only caching the zones in the Internal View, not all
public stuff looked up by internal clients?
I say this because I get fast responses to internal servers, but slow if
at all to external ones.
Grasping here because my search foo is weak and I can't find where it is
defined exactly what IS cached.
On 8/3/22 10:52, Robert Moskowitz via bind-users wrote:
> thanks Greg. Yes I need to figure out how to troubleshoot this. But
> here is some stuff:
>
> # cat resolv.conf
> # Generated by NetworkManager
> search attlocal.net htt-consult.com
> nameserver 23.123.122.146
> nameserver 2600:1700:9120:4330::1
>
> My server is 23.123.122.146. That IPv6 addr is my ATT router.
>
> # cat named.conf
> include "/etc/named/named.acl";
>
> options {
> listen-on port 53 { any; };
> listen-on-v6 port 53 { any; };
> use-v4-udp-ports { range 10240 65535; };
> use-v6-udp-ports { range 10240 65535; };
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { localhost; };
>
> dnssec-enable no;
> dnssec-validation no;
> bindkeys-file "/etc/named.iscdlv.key";
> managed-keys-directory "/var/named/dynamic";
> pid-file "/run/named/named.pid";
> session-keyfile "/run/named/session.key";
> };
>
> logging { channel default_debug {
> file "data/named.run";
> severity dynamic; };};
>
> view "internal"
> { include "/etc/named/named.internal";};
>
> view "external"
> { include "/etc/named/named.external";};
>
> include "/etc/named/rndc.key";
> include "/etc/named.root.key";
>
> # cat named.acl
> acl "httslaves" {
> // address of NSs
> 208.83.69.35; // ns1.mudkips.net
> 208.83.66.130; // ns2.mudkips.net
> 63.68.132.50; // ns1.icsl.net
> 2607:f4b8:2600:1::1; // ns1.mudkips.net
> 2607:f4b8:2600:6::1; // ns2.mudkips.net
> };
>
> acl "httnets" {
> 127.0.0.1;
> 23.123.122.144/28;
> 192.168.32.0/24;
> 192.168.64.0/24;
> 192.168.96.0/24;
> 192.168.160.0/23;
> 192.168.128.0/23;
> 192.168.192.0/22;
> 192.168.224.0/24;
> ::1;
> 2600:1700:9120:4330::/64;
> };
>
>
> # cat named.internal
>
> match-clients { httnets; };
> match-destinations { httnets; };
> allow-query { httnets; };
> allow-query-cache { httnets; };
> allow-recursion { any; };
> recursion yes;
> empty-zones-enable yes;
>
> zone "." IN {
> type hint;
> file "named.ca"; };
>
> include "/etc/named.rfc1912.zones";
>
> zone "htt-consult.com" {
> type master;
> file "httin-consult.com.zone"; };
>
> zone "labs.htt-consult.com" {
> type master;
> file "labs.htt-consult.com.hosts"; };
> zone "intelcon.htt-consult.com" {
> type master;
> file "intelcon.htt-consult.com.hosts"; };
> zone "mobile.htt-consult.com" {
> type master;
> file "mobile.htt-consult.com.hosts"; };
> zone "test.htt-consult.com" {
> type master;
> file "test.httin-consult.com.hosts"; };
> zone "128.168.192.in-addr.arpa" {
> type master;
> file "128.168.192.in-addr.arpa.zone"; };
> zone "0-24.128.168.192.in-addr.arpa" {
> type master;
> file "0-24.128.168.192.in-addr.arpa.zone"; };
> zone "htt" {
> type master;
> file "htt.zone"; };
> zone "home.htt" {
> type master;
> file "home.htt.zone"; };
>
>
> Do you also want my named.external?
>
>
> On 8/3/22 09:39, Greg Choules wrote:
>> Hi Robert.
>> May we see the file /etc/resolv.conf and your BIND configuration?
>> It's difficult to guess what might be going on with only a small
>> snippet of information.
>> If you "ping somewhere" (or "ssh a-server", or whatever) the OS will
>> consult resolv.conf to determine where to send DNS queries. If that's
>> not your local instance of BIND then you could be looking for trouble
>> in the wrong place.
>>
>> If you *do* have an address of the local machine as the first
>> 'nameserver' entry in resolv.conf you will need to know what that
>> query looks like to determine how BIND is going to handle it.
>> You also need to know what BIND will try and do when it does receive
>> queries.
>>
>> Packet captures are your friend here, using tcpdump (to disk, not to
>> screen). Gather evidence first, then make theories.
>>
>> Cheers, Greg
>>
>> On Wed, 3 Aug 2022 at 14:29, Robert Moskowitz <rgm at htt-consult.com>
>> wrote:
>>
>> Part of my problem is that caching does not seem to be working in my
>> internal view.
>>
>> Something is happening such that my internal systems AND the server
>> itself cannot resolve names and looses it even 5 min later,
>> indicating
>> not caching.
>>
>> I read https://kb.isc.org/docs/aa-00851
>>
>> In my include for the internal view (named.internal) I have:
>>
>> match-clients { httnets; };
>> match-destinations { httnets; };
>> allow-query { httnets; };
>> allow-query-cache { httnets; };
>> allow-recursion { any; };
>> recursion yes;
>> empty-zones-enable yes;
>>
>> Yet I get on my DNS server:
>>
>> ping www.google.com <http://www.google.com>
>> ping: www.google.com <http://www.google.com>: Name or service not
>> known
>>
>> Then later it works.
>>
>> Then later it doesn't again.
>>
>> Sigh. If at least caching was working for internal use, I would
>> be able
>> to work more smoothy?
>>
>>
>>
>>
>> --
>> Visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> ISC funds the development of this software with paid support
>> subscriptions. Contact us at https://www.isc.org/contact/ for
>> more information.
>>
>>
>> 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/20220803/cca92de8/attachment-0001.htm>
More information about the bind-users
mailing list