caching does not seem to be working for internal view
Greg Choules
gregchoules+bindusers at googlemail.com
Wed Aug 3 20:56:58 UTC 2022
Hi Robert.
Turn on query logging by doing "rndc querylog". You should see a message
saying that has been done in "named.log", to where each query will now be
logged. If you have views, part of the query log will contain which view
was matched. So this will tell you two things:
1. If the queries you are making are actually being handled by BIND at
all.
2. If they are, which view handled them.
Try that and see what you discover.
By the way, if you want to see a snapshot of the cache you will have to
dump it to disk using "rndc dumpdb -all", This will produce a file called
"named_dump.db" in the working directory. Commonly this will be the same
location as your zone files. It's a text file, so you can look through it
with cat/more/less etc.
Cheers, Greg
On Wed, 3 Aug 2022 at 21:23, Robert Moskowitz <rgm at htt-consult.com> wrote:
> This is boarderline not thinking on my part.
>
> OF COURSE those FQDNs resolve fast; they are in local ZOne files. No
> lookup needed.
>
> Sheesh.
>
> "Slow down, you move to fast. Got to make the Mornin' last!" :)
>
> On 8/3/22 14:43, Robert Moskowitz wrote:
>
> 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
>> ping: 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/4a25b1f3/attachment-0001.htm>
More information about the bind-users
mailing list