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

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

 



On pe, 26 helmi 2021, Lennart Poettering wrote:
On Mi, 24.02.21 22:08, Alexander Bokovoy (abokovoy@xxxxxxxxxx) wrote:

I think one of the issues reported in the discussion you mention was
that systemd-resolved considered invalid a DNS= line where addresses
were separated by a comma rather than space. Can systemd-resolved be
improved to allow common separators like both space and comma?

I am not a fan of such needless ambiguity, and it's not going to
retroactively fix the original reporter's configuration that has now
been fixed anyway... Moreover, across the systemd codebase in
configuration files we so far stuck to using mostly whitespace for
separating multiple values on the same config option line.

The thing is: separator characters end up being used for various other
purposes sooner or later. For example the DNS= lines in resolved.conf
already uses:

1. Dots (".") for separating IPV4 address bytes
2. Colons (":") for separating IPv6 address parts, as well as separating
  port numbers from the IP addres
3. Brackets ("[]") for separating ipv6 addresses from the rest of the
  construct
4. Percent ("%") characters to separate interface info from the rest
5. Hash ("#") characters to separate SNI host name specifications

Now, we currently don't use "," and ";" for separators here, but as
these things keep growing we might need them for something soon too.

I understand your willingness to apply the same rules for multiple
options in the config files owned by systemd codebase. This, however, is
a content pushed out by external parties, not a part of systemd proper.

As pointed out by Michael in this discussion, Digital Ocean uses ',' to
separate DNS servers pushed out by cloud-init. I don't think they are
alone in this.

Digital Ocean updates pushed with cloud-init use. Cloud-init does not
have any native support for systemd-resolved. It means it writes
something that systemd-resolved imports into own state. I would argue
that your arguments for systemd-wide configuration rules do not apply
here. Either you'd need to fix cloud-init or allow for a variance in
input data that comes to systemd-resolved from third parties.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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