[Bug 1731522] Re: systemd-resolved fails to fall back to TCP for large records (Cannot ping pod51041.outlook.com but can dig.)

Fri Jan 26 19:48:29 UTC 2018

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
Foundations Bugs, which is subscribed to systemd in 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.)

Status in systemd package in Ubuntu:
  Triaged

Bug description:
  Trying to resolve pod51041.outlook.com's domain name seems to fail for
  applications:

  $ ping pod51041.outlook.com
  ping: pod51041.outlook.com: Temporary failure in name resolution

  (Also can't access via thunderbird).

  However, it seems to work directly via systemd-resolve:

  $ systemd-resolve pod51041.outlook.com
  pod51041.outlook.com: 40.97.160.2
                        40.97.126.50
                        132.245.38.194
                        40.97.147.194
                        132.245.41.34
                        40.97.176.2
                        40.97.150.242
                        40.97.85.114
                        40.97.120.50
                        40.97.85.2
                        40.97.176.34
                        40.97.138.242
                        40.97.166.18
                        40.97.120.162
                        40.97.119.82
                        40.97.176.18
                        40.97.85.98
                        40.97.134.34
                        40.97.84.18

  -- Information acquired via protocol DNS in 2.5ms.
  -- Data is authenticated: no

  It also works with dig and nslookup.

  Not quite sure why this is the case, I've spotted this issue upstream
  that looks similar: https://github.com/systemd/systemd/issues/6520.
  However, I'm not familiar enough with DNS to tell if it is the same
  issue.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: systemd 234-2ubuntu12
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl zcommon znvpair
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: MATE
  Date: Fri Nov 10 13:10:02 2017
  InstallationDate: Installed on 2017-11-10 (0 days ago)
  InstallationMedia: Ubuntu-MATE 17.10 "Artful Aardvark" - Release amd64 (20171018)
  MachineType: LENOVO 2324BB9
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.13.0-16-generic.efi.signed root=UUID=8ab6bf88-72bd-4308-941e-3b36d4d7811b ro rootflags=subvol=@ quiet splash vt.handoff=7
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 03/03/2016
  dmi.bios.vendor: LENOVO
  dmi.bios.version: G2ETA6WW (2.66 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 2324BB9
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: dmi:bvnLENOVO:bvrG2ETA6WW(2.66):bd03/03/2016:svnLENOVO:pn2324BB9:pvrThinkPadX230:rvnLENOVO:rn2324BB9:rvrNotDefined:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.family: ThinkPad X230
  dmi.product.name: 2324BB9
  dmi.product.version: ThinkPad X230
  dmi.sys.vendor: LENOVO

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1731522/+subscriptions