caching does not seem to be working for internal view
Robert Moskowitz
rgm at htt-consult.com
Wed Aug 3 20:23:18 UTC 2022
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 <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/0de26925/attachment-0001.htm>
More information about the bind-users
mailing list