This bug was fixed in the package systemd - 239-7ubuntu15

---------------
systemd (239-7ubuntu15) disco; urgency=medium

  * core: set /run size to 10%, like initramfs-tools does.
    Currently there is a difference between initrd and initrd-less boots,
    w.r.t. size= mount option of /run. This yields different runtime journald 
caps
    (1% vs 10%), and on dense deployments of containers may result in OOM kills.
    (LP: #1799251)
    File: 
debian/patches/debian/UBUNTU-core-set-run-size-to-10-like-initramfs-tools-does.patch
    
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=1fac2568fe716dc1a41bada78293dc6327a6df0d

  * resolved: Increase size of TCP stub replies.
    DNS_PACKET_PAYLOAD_SIZE_MAX is limiting the size of the stub replies to
    512 with EDNS off or 4096 with EDNS on, without checking the protocol
    used. This makes TCP replies for clients without EDNS support to be
    limited to 512, making the truncate flag useless if the query result is
    bigger than 512 bytes.
    This commit increases the size of TCP replies to DNS_PACKET_SIZE_MAX
    Fixes: #10816
    (cherry picked from commit e6eed9445956cfa496e1db933bfd3530db23bfce)
    (LP: #1804487)
    Author: Victor Tapia
    File: debian/patches/resolved-Increase-size-of-TCP-stub-replies.patch
    
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=702a4566174c4d2bd84b70805107cfc1a7c128cc

 -- Dimitri John Ledkov <x...@ubuntu.com>  Mon, 03 Dec 2018 13:49:24
+0000

** Changed in: systemd (Ubuntu Disco)
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 Released
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 Released
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/~group.of.nepali.translators
Post to     : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help   : https://help.launchpad.net/ListHelp

Reply via email to