I can confirm this problem. 'dig' works because by default it's only
asking for A records; but applications on ipv6-enabled clients will ask
for both A and AAAA records, and if I query AAAA for this name, the
response is too big to fit in a udp packet:
$ nslookup -q=aaaa pod51041.outlook.com 192.168.15.1
;; Truncated, retrying in TCP mode.
Server: 192.168.15.1
Address: 192.168.15.1#53
Non-authoritative answer:
pod51041.outlook.com has AAAA address 2603:1036:d02::2
pod51041.outlook.com has AAAA address 2603:1036:d02:6::2
pod51041.outlook.com has AAAA address 2603:1036:d02:7::2
pod51041.outlook.com has AAAA address 2a01:111:f400:5201::2
pod51041.outlook.com has AAAA address 2a01:111:f400:f370::2
pod51041.outlook.com has AAAA address 2603:1036:3:cc::2
pod51041.outlook.com has AAAA address 2603:1036:3:108::2
pod51041.outlook.com has AAAA address 2603:1036:4:6f::2
pod51041.outlook.com has AAAA address 2603:1036:4:71::2
pod51041.outlook.com has AAAA address 2603:1036:101:3a::2
pod51041.outlook.com has AAAA address 2603:1036:102:53::2
pod51041.outlook.com has AAAA address 2603:1036:102:cb::2
pod51041.outlook.com has AAAA address 2603:1036:405:3b::2
pod51041.outlook.com has AAAA address 2603:1036:804:1::2
pod51041.outlook.com has AAAA address 2603:1036:804:a::2
pod51041.outlook.com has AAAA address 2603:1036:902:a3::2
pod51041.outlook.com has AAAA address 2603:1036:906:4f::2
pod51041.outlook.com has AAAA address 2603:1036:d01:1::2
Authoritative answers can be found from:
outlook.com nameserver = ns2.msft.net.
outlook.com nameserver = ns3.msft.net.
outlook.com nameserver = ns1.msft.net.
outlook.com nameserver = ns2a.o365filtering.com.
outlook.com nameserver = ns4.msft.net.
outlook.com nameserver = ns1a.o365filtering.com.
outlook.com nameserver = ns4a.o365filtering.com.
ns1.msft.net internet address = 208.84.0.53
ns1.msft.net has AAAA address 2620:0:30::53
ns2.msft.net internet address = 208.84.2.53
ns2.msft.net has AAAA address 2620:0:32::53
ns3.msft.net internet address = 193.221.113.53
ns3.msft.net has AAAA address 2620:0:34::53
ns4.msft.net internet address = 208.76.45.53
ns4.msft.net has AAAA address 2620:0:37::53
ns1a.o365filtering.com internet address = 157.56.110.11
ns2a.o365filtering.com internet address = 157.56.116.52
ns4a.o365filtering.com internet address = 157.55.133.11
$
If I try this against systemd-resolved, I see:
$ nslookup -q=aaaa pod51041.outlook.com
;; Warning: Message parser reports malformed message packet.
;; Truncated, retrying in TCP mode.
;; Connection to 127.0.0.53#53(127.0.0.53) for pod51041.outlook.com failed:
connection refused.
$
So the problem is that systemd-resolved is not handling tcp requests at
all.
** Changed in: systemd (Ubuntu)
Importance: Undecided => High
** Changed in: systemd (Ubuntu)
Status: Confirmed => Triaged
** Summary changed:
- systemd-resolved fails to fall back to TCP for large records (Cannot ping
pod51041.outlook.com but can dig.)
+ systemd-resolved does not listen on TCP port, cannot serve large records
(Cannot ping pod51041.outlook.com but can dig.)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1731522
Title:
systemd-resolved does not listen on TCP port, cannot serve large
records (Cannot ping pod51041.outlook.com but can dig.)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1731522/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
