[Touch-packages] [Bug 2008964] Re: resolved falls back to a non-preferred name server when the preferred name server appears to be working.
I was able to reproduce on Ubuntu 20.04 too (by switching the active network interface), so this may not be a recent regression. -- 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/2008964 Title: resolved falls back to a non-preferred name server when the preferred name server appears to be working. Status in systemd package in Ubuntu: New Bug description: This is split from bug #2007728. On a network with multiple DNS servers provided by DHCP, the "Current DNS Server" shown by `resolvectl status` is sometimes not the first server or even the second server, even when those servers appear to be working (and other hosts continue to use them). This appears to occur on Ubuntu 22.04 but not on Ubuntu 20.04, Ubuntu 18.04, or Windows 10. RFC 2132 section 3.8 provides that servers are listed in order of preference. It seems that the correct behavior is that resolved picks as its "Current DNS Server" the first reachable server in the list provided by the DHCP server. The observed behavior is that resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. My hypothesis is that there is some name server availability check that is too stringent and that there is no mechanism to retry the preferred server after that check fails. I have not looked at the code or captured packets. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2008964/+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
[Touch-packages] [Bug 2007728] Re: resolved results differ from those from its current upstream server.
I split the "Current DNS Server" issue into bug #2008964. -- 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: Incomplete 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
[Touch-packages] [Bug 2008964] [NEW] resolved falls back to a non-preferred name server when the preferred name server appears to be working.
Public bug reported: This is split from bug #2007728. On a network with multiple DNS servers provided by DHCP, the "Current DNS Server" shown by `resolvectl status` is sometimes not the first server or even the second server, even when those servers appear to be working (and other hosts continue to use them). This appears to occur on Ubuntu 22.04 but not on Ubuntu 20.04, Ubuntu 18.04, or Windows 10. RFC 2132 section 3.8 provides that servers are listed in order of preference. It seems that the correct behavior is that resolved picks as its "Current DNS Server" the first reachable server in the list provided by the DHCP server. The observed behavior is that resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. My hypothesis is that there is some name server availability check that is too stringent and that there is no mechanism to retry the preferred server after that check fails. I have not looked at the code or captured packets. ** 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/2008964 Title: resolved falls back to a non-preferred name server when the preferred name server appears to be working. Status in systemd package in Ubuntu: New Bug description: This is split from bug #2007728. On a network with multiple DNS servers provided by DHCP, the "Current DNS Server" shown by `resolvectl status` is sometimes not the first server or even the second server, even when those servers appear to be working (and other hosts continue to use them). This appears to occur on Ubuntu 22.04 but not on Ubuntu 20.04, Ubuntu 18.04, or Windows 10. RFC 2132 section 3.8 provides that servers are listed in order of preference. It seems that the correct behavior is that resolved picks as its "Current DNS Server" the first reachable server in the list provided by the DHCP server. The observed behavior is that resolved sometimes picks as its "Current DNS Server" some server other than the first reachable server in the list. My hypothesis is that there is some name server availability check that is too stringent and that there is no mechanism to retry the preferred server after that check fails. I have not looked at the code or captured packets. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2008964/+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
[Touch-packages] [Bug 2007728] Re: resolved results differ from those from its current upstream server.
Alright. The failure on a specific .local domain is consistent. I have not tested adding a non-".local" domain to the preferred name server, but your explanation that resolved now fully excludes .local from DNS queries makes sense. I still think that this is undesirable behavior since it breaks common legacy configurations without a clear indication of what the issue is and without an easy fix even for those who know what is broken. -- 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: Incomplete 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
[Touch-packages] [Bug 2007728] Re: resolved results differ from those from its current upstream server.
Now that you mention it, I'm not sure. Something was definitely inconsistent, but the inconsistency may have been across different internal names rather than across requests on the same name, and it did not occur to me at the time that the .local names were in a different category. I will check tomorrow and report back. -- 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: Incomplete 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
[Touch-packages] [Bug 2007728] Re: resolved results differ from those from its current upstream server.
Would you describe the "as documented" behavior? It still seems wacky to me that resolved returns the DNS result the majority of the time but not all of the time. If the design intent is to use only mDNS for .local domains, it ought to ignore DNS entirely for those domains. Inconsistent behavior means that a configuration can test as correct, fail in the field, fail to replicate the failure, and frustrate isolation of the problem. I think that the earlier behavior makes a lot more sense and would prefer to return to it. Are you able to replicate the issue? Given how closely the two possibly separate problems are related and their similar effects, I am inclined to wait on filing a second bug report on the server selection until it is clear that these are in fact separate issues. The fact that no other hosts on the network exhibit the problem (a highly symptomatic one since it breaks most services) suggests that this is not an issue of both internal servers failing at the same time. -- 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: Incomplete 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
[Touch-packages] [Bug 2007728] Re: resolved results differ from those from its current upstream server.
The first two servers do indeed provide the .local domains. The possible violation of RFC 6762 does not explain the inconsistency of the results or the regression from Ubuntu 18.04 and Ubuntu 20.04. There is no case in which the correct behavior for a single configuration is to query the "Current DNS Server" for the .local name sometimes and mDNS other times. This also does not explain why the "Current DNS Server" selection sometimes fails to observe the order provided in the DHCP response. If resolved ignores the server ordering and the low-priority servers lack the internal names, even switching the suffix of the internal names is insufficient to provide the desired results. We have reverted the clients in question to Ubuntu 20.04 for now, and they work correctly. -- 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: Incomplete 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
[Touch-packages] [Bug 2007728] [NEW] resolved results differ from those from its current upstream server.
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
