@vtapia, did you also test if 'ping' and/or 'telnet' DNS resolution was fixed as well? i.e. currently:
ubuntu@lp1804487:~$ ping testing.irongiantdesign.com ping: testing.irongiantdesign.com: Temporary failure in name resolution ubuntu@lp1804487:~$ telnet testing.irongiantdesign.com telnet: could not resolve testing.irongiantdesign.com/telnet: Temporary failure in name resolution ubuntu@lp1804487:~$ ssh testing.irongiantdesign.com ssh: Could not resolve hostname testing.irongiantdesign.com: Temporary failure in name resolution ubuntu@lp1804487:~$ host testing.irongiantdesign.com testing.irongiantdesign.com has address 253.0.0.23 testing.irongiantdesign.com has address 253.0.0.6 testing.irongiantdesign.com has address 253.0.0.28 testing.irongiantdesign.com has address 253.0.0.25 testing.irongiantdesign.com has address 253.0.0.22 testing.irongiantdesign.com has address 253.0.0.5 testing.irongiantdesign.com has address 253.0.0.10 testing.irongiantdesign.com has address 253.0.0.4 testing.irongiantdesign.com has address 253.0.0.16 testing.irongiantdesign.com has address 253.0.0.2 testing.irongiantdesign.com has address 253.0.0.7 testing.irongiantdesign.com has address 253.0.0.26 testing.irongiantdesign.com has address 173.236.154.252 testing.irongiantdesign.com has address 253.0.0.21 testing.irongiantdesign.com has address 253.0.0.27 testing.irongiantdesign.com has address 253.0.0.13 testing.irongiantdesign.com has address 253.0.0.3 testing.irongiantdesign.com has address 253.0.0.1 testing.irongiantdesign.com has address 253.0.0.24 testing.irongiantdesign.com has address 253.0.0.12 testing.irongiantdesign.com has address 253.0.0.9 testing.irongiantdesign.com has address 253.0.0.20 testing.irongiantdesign.com has address 253.0.0.8 testing.irongiantdesign.com has address 253.0.0.15 testing.irongiantdesign.com has address 253.0.0.19 testing.irongiantdesign.com has address 253.0.0.17 testing.irongiantdesign.com has address 253.0.0.18 testing.irongiantdesign.com has address 253.0.0.14 testing.irongiantdesign.com has address 253.0.0.11 That doesn't appear fixed with the latest systemd...? ubuntu@lp1804487:~$ dpkg -l |grep 'ii systemd ' ii systemd 239-7ubuntu10.5 amd64 system and service manager ubuntu@lp1804487:~$ ping testing.irongiantdesign.com ping: testing.irongiantdesign.com: Temporary failure in name resolution ubuntu@lp1804487:~$ telnet testing.irongiantdesign.com telnet: could not resolve testing.irongiantdesign.com/telnet: Temporary failure in name resolution ubuntu@lp1804487:~$ ssh testing.irongiantdesign.com ssh: Could not resolve hostname testing.irongiantdesign.com: Temporary failure in name resolution -- 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/1804487 Title: systemd-resolved has issues when the answer is over 512 bytes with EDNS disabled Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Xenial: Invalid Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: Fix Committed Status in systemd source package in Disco: Fix Committed Status in systemd package in Debian: Fix Released Bug description: [Impact] TCP stub is cutting down the payload to 512 bytes when EDNS is disabled. This makes non-EDNS clients (nslookup) receive a "shortened" answer even when UDP returns a truncated reply for a new TCP query. For instance, - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 In the second case, no-EDNS, TCP should provide the complete answer, but it's capped at UDP's size. [Test Case] Query systemd-resolved with a domain name that resolves to multiple (lots.. 30+) A records. A client with EDNS support (dig) will receive all of them, a client without support (nslookup or dig +noedns) will have a truncated list. Using the example above: EDNS: dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l non-EDNS: dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l [Regression potential] Minimal. This change only affects TCP requests, and the new size is already used in the code for other requests. [Other Info] Upstream bug: https://github.com/systemd/systemd/issues/10816 Fixed upstream with commit: https://github.com/systemd/systemd/commit/e6eed9445956cfa496e1db933bfd3530db23bfce [Original Description] Querying a domain name that has >512 bytes in records (e.g. 30+ A records), the number of results depends on the DNS client used: - If the client supports EDNS: $ dig +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 30 - If the client does not support EDNS: $ dig +noedns +noall +answer testing.irongiantdesign.com @127.0.0.53 | wc -l 29 Normally a client that doesn't support EDNS would receive a truncated reply from the initial UDP connection (limited by the spec to 512 bytes) and a second query would be established via TCP to receive the complete results. In this case, the number of results is the same regardless of the protocol used (29). Upstream bug: https://github.com/systemd/systemd/issues/10816 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1804487/+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
