Public bug reported:
On a network with multiple DNS servers provided by DHCP, only the first
two of which cover local names, resolved returns universally known names
but fails to return the special names even when the "Current DNS Server"
shown by `resolvectl status` returns the special names.
Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS servers
with the local names. Windows servers with Active Directory enabled in
this case. The DHCP server (a Cisco 4451 in this case) provides DNS
servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and 8.8.8.8. `resolvectl
status` shows all of these as "DNS Servers" and 172.16.9.5 as the
"Current DNS Server".
`host localdomain.local` returns SRVFAIL, and `host localdomain.local
127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
returns the correct result. This all happens regardless of the "Current
DNS Server".
Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons that
are not clear even when the other servers are working properly, which
seems to violate the principle of RFC 2132 section 3.8 that servers are
listed in order of preference.
So, in short, it seems that the correct behavior is that (1) resolved
returns results consistent with its "Current DNS Server" and (2)
resolved picks as its "Current DNS Server" the first reachable server in
the list. The current behavior is that (1) resolved returns results
sometimes inconsistent with its "Current DNS Server" and (2) resolved
sometimes picks as its "Current DNS Server" some server other than the
first reachable server in the list. The first issue is consistently
reproducible, and the second is readily reproducible in a short period
of time.
The problem appears on Ubuntu 22.04 and seems not to be present on
Ubuntu 18.04.
** Affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2007728
Title:
resolved results differ from those from its current upstream server.
Status in systemd package in Ubuntu:
New
Bug description:
On a network with multiple DNS servers provided by DHCP, only the
first two of which cover local names, resolved returns universally
known names but fails to return the special names even when the
"Current DNS Server" shown by `resolvectl status` returns the special
names.
Suppose that 172.16.9.5 and 172.16.10.5 are the two internal DNS
servers with the local names. Windows servers with Active Directory
enabled in this case. The DHCP server (a Cisco 4451 in this case)
provides DNS servers 172.16.9.5, 172.16.10.5, 192.168.0.1, and
8.8.8.8. `resolvectl status` shows all of these as "DNS Servers" and
172.16.9.5 as the "Current DNS Server".
`host localdomain.local` returns SRVFAIL, and `host localdomain.local
127.0.0.53` returns SRVFAIL, but `host localdomain.local 172.16.9.5`
returns the correct result. This all happens regardless of the
"Current DNS Server".
Sometimes the "Current DNS Server" switches to 8.8.8.8 for reasons
that are not clear even when the other servers are working properly,
which seems to violate the principle of RFC 2132 section 3.8 that
servers are listed in order of preference.
So, in short, it seems that the correct behavior is that (1) resolved
returns results consistent with its "Current DNS Server" and (2)
resolved picks as its "Current DNS Server" the first reachable server
in the list. The current behavior is that (1) resolved returns results
sometimes inconsistent with its "Current DNS Server" and (2) resolved
sometimes picks as its "Current DNS Server" some server other than the
first reachable server in the list. The first issue is consistently
reproducible, and the second is readily reproducible in a short period
of time.
The problem appears on Ubuntu 22.04 and seems not to be present on
Ubuntu 18.04.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2007728/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
