Re: systemd-resolved fallback DNS servers: usability vs. GDPR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tadej,

thanks for confirmation.

On 2/23/21 10:37 AM, Tadej Janež wrote:
> Petr,
> 
> thanks for looking into this.
> 
> On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote:
>> After a quick glance at cloud-init code, it seems to me it does not
>> check /etc/resolv.conf for symlinks.
>>
>> It just reads /etc/resolv.conf if it is a file, then writes its own
>> nameservers into target. I have seen no rm of original
>> /etc/resolv.conf,
>> so I guess it rewritten target of symlink on Fedora 33:
>> /run/systemd/resolve/stub-resolv.conf
> 
> Indeed, cloud-init just "blindly" amends the /etc/resolv.conf file
> which is a symlink to /run/systemd/resolve/stub-resolv.conf and hence
> gets overwritten by systemd-resolved.
> 
> Here are the relevant snippets from a DigitalOcean instance's
> /var/log/cloud-init.log:
> 
> ... trimmed ...
>  digitalocean.py[DEBUG]: added dns servers: ['67.207.67.2',
> '67.207.67.3']
> ... trimmed ...
> __init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list:
> None
> util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth1 -
> wb: [644] 212 bytes
> util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
> scripts/ifcfg-eth1 (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
> scripts/ifcfg-eth1 (recursive=False)
> util.py[DEBUG]: Writing to /etc/sysconfig/network-scripts/ifcfg-eth0 -
> wb: [644] 287 bytes
> util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
> scripts/ifcfg-eth0 (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for /etc/sysconfig/network-
> scripts/ifcfg-eth0 (recursive=False)
> util.py[DEBUG]: Reading from /etc/resolv.conf (quiet=False)
> util.py[DEBUG]: Read 729 bytes from /etc/resolv.conf
> util.py[DEBUG]: Writing to /etc/resolv.conf - wb: [644] 846 bytes
> util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub-
> resolv.conf (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for /run/systemd/resolve/stub-
> resolv.conf (recursive=False)
> util.py[DEBUG]: Writing to /etc/NetworkManager/conf.d/99-cloud-
> init.conf - wb: [644] 89 bytes
> util.py[DEBUG]: Restoring selinux mode for
> /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for
> /etc/NetworkManager/conf.d/99-cloud-init.conf (recursive=False)
> util.py[DEBUG]: Writing to /etc/udev/rules.d/70-persistent-net.rules -
> wb: [644] 192 bytes
> util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70-
> persistent-net.rules (recursive=False)
> util.py[DEBUG]: Restoring selinux mode for /etc/udev/rules.d/70-
> persistent-net.rules (recursive=False)
> ... trimmed ...
> 
>> I think there are two possible fixes:
>> * cloud-init would check the symlink and target of etc/resolv.conf.
>> If
>> it points to /run/systemd/resolve/*, write DNS=x y into
>> /etc/systemd/resolved.conf.d/*cloud-init.conf
> 
> I think this option would be preferred.
> 
>> * clound-init would always delete etc/resolv.conf before it writes
>> into
>> it, if it was symlink.
> 
> I guess this is a simple solution that would work, but from what I
> understand it would also disable the use of systemd-resolved?

Well, partially. It wouldn't disable systemd-resolved service, but would
not direct DNS messages to resolved. It would still cache requests done
via nss, typically via getaddrinfo() or gethostbyname() function. That
was intention of cloud-init anyway. Personally I would prefer cache on
the host instead of in each container.
> 
>> * systemd-resolved would check contents of link target of
>> /etc/resolv.conf on startup. If it leads to systemd, try parsing its
>> contents. If it does not look like managed contents of systemd,
>> assume
>> it might be misdirected resolv.conf configuration. Store it and wait
>> for
>> DHCP configuration. If no better configuration arrives, use
>> nameservers
>> from misdirected file. Would have to restore original resolv.conf on
>> shutdown to keep working after restarts. Should move it to
>> fallback.conf
>> and use it instead of built-in fallbacks?
> 
> This seems too complex and error prone.
> 
> Regards,
> Tadej
It could just always move file without its own header to
/run/systemd/resolved/fallback.conf (or maybe some permanent). When no
better configuration was set, use this file as nameservers source,
instead of built-in defaults. It would omit saving that files.

Sure, this part is more complex. But only this part can fix this problem
from inside the container IMO. Ie. we could fix it faster for any
involved parties.

I don't really run any container on any cloud service so this is just my
guess. Who uses cloud-init to prepare the container? If it is used by
cloud provider, I would expect slow updates and conservative behavior.
Even if we fix it immediately, how fast would appear on the service? I
think the fix from within can be much sooner be used by users.

Who uses cloud-init to prepare containers? Is it end user on his system?

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemensik@xxxxxxxxxx
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux