,Re: caching does not seem to be working for internal view

[Timothe Litt]

Hmm.  Your resolv.conf says that it's written by NetworkManager.

What I suggested should have stopped it from updating resolv.conf.

See 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_networking/manually-configuring-the-etc-resolv-conf-file_configuring-and-managing-networking

After restarting the service, did you edit (or replace) resolv.conf to 
remove the AT&T address?

If not, stop here & edit the file.

If so, perhaps some other manager is editing the file without replacing 
the comment.

Check to see if resolv.conf is a symlink - some managers (e.g. 
systemd-resolved) will do that.  Not sure when/if it found its way to 
centos (I don't run it), but if it's there, systemctl stop & disable 
it.  It would be running on 127.0.0.53:53, but it usually points 
resolv.conf to itself.

The other managers that I know of aren't in redhat distributions.

You may need to use auditing to identify what is writing the file.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 03-Aug-22 14:39, Robert Moskowitz wrote:
>
>
> On 8/3/22 12:59, Timothe Litt wrote:
>>
>> Try
>>
>> echo -e "[main]\ndns=none" > /etc/NetworkManager/conf.d/no-dns.conf
>> systemctl restart NetworkManager.service
>>
>
> Same content in resolv.conf.  BTW this is on Centos7.
>
>> Timothe Litt
>> ACM Distinguished Engineer
>> --------------------------
>> This communication may not represent the ACM or my employer's views,
>> if any, on the matters discussed.
>> On 03-Aug-22 12:36, Robert Moskowitz wrote:
>>>
>>>
>>> On 8/3/22 11:35, Timothe Litt wrote:
>>>> On 03-Aug-22 10:53, bind-users-request at lists.isc.org wrote:
>>>>> # cat resolv.conf
>>>>>
>>>>> My server is 23.123.122.146.  That IPv6 addr is my ATT router.
>>>>
>>>>
>>>> You don't want to do that.  The ATT router will not know how to 
>>>> resolve internal names.  There is no guarantee that your client 
>>>> resolver will try nameservers in order.  If you want a backup, run 
>>>> a second instance of named.
>>>>
>>>> As for the intermittent issues with resolving external names, 
>>>> that's frequently a case of hitting different nameservers.  Or a 
>>>> firewall.
>>>>
>>>> Get rid of the ATT router first.  Then as suggested, a packet trace 
>>>> will show what happens (if it still does - it could be that the ATT 
>>>> router's resolver is at fault).
>>>>
>>>
>>> Thank you for your advice.  my ifcfg-eth0 has:
>>>
>>> DEVICE="eth0"
>>> BOOTPROTO=none
>>> ONBOOT="yes"
>>> TYPE="Ethernet"
>>> NAME="eth0"
>>> MACADDR=02:67:15:00:00:02
>>> MTU=1500
>>> DNS1=23.123.122.146
>>> GATEWAY="23.123.122.158"
>>> IPADDR="23.123.122.146"
>>> NETMASK="255.255.255.240"
>>> IPV6INIT="yes"
>>>
>>> And I am ASSuMEing that it is that IPV6INIT that is providing that 
>>> IPv6 addr in resolv.cat.  So I added:
>>>
>>> DNS2=192.168.224.2
>>>
>>> And now:
>>>
>>> # cat /etc/resolv.conf
>>> # Generated by NetworkManager
>>> search attlocal.net htt-consult.com
>>> nameserver 23.123.122.146
>>> nameserver 192.168.224.2
>>> nameserver 2600:1700:9120:4330::1
>>>
>>> ARGH!
>>>
>>> I want the IPv6 addr from my firewall/gateway.  But I don't want 
>>> that IPv6 nameserver!
>>>
>>> So I added the IPv6 address for my server.  I had not done this as 
>>> ATT has said there is no assurance with the IPv6 addresses may 
>>> change.  So I added:
>>>
>>> DNS3=2600:1700:9120:4330::49
>>>
>>> and now:
>>>
>>> # cat /etc/resolv.conf
>>> # Generated by NetworkManager
>>> search attlocal.net htt-consult.com
>>> nameserver 23.123.122.146
>>> nameserver 192.168.224.2
>>> nameserver 2600:1700:9120:4330::1
>>> # NOTE: the libc resolver may not support more than 3 nameservers.
>>> # The nameservers listed below may not be recognized.
>>> nameserver 2600:1700:9120:4330::49
>>>
>>> Sigh.  I have to take that dynamic IPv6 assignment.  But I want to 
>>> stop it pushing into my resolv.conf.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220803/d7ba3d12/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220803/d7ba3d12/attachment.sig>