,Re: caching does not seem to be working for internal view
Timothe Litt
litt at acm.org
Wed Aug 3 19:10:39 UTC 2022
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>
More information about the bind-users
mailing list