** Description changed:

+ [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.
+ 
+ [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 
+ 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

** Description changed:

  [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.
+ 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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1804487

Title:
  systemd-resolved has issues when the answer is over 512 bytes with
  EDNS disabled

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

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to