aha:
ddstreet@lp1886128:~$ sudo iptables -n -t security -L OUTPUT
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0168.63.129.16owner UID match 0
DROP tcp -- 0.0.0.0/0168.63.129.16
To repro on azure instance:
ddstreet@lp1886128:~$ systemd-resolve --status | grep Servers
DNS Servers: 168.63.129.16
ddstreet@lp1886128:~$ dig +retries=0 +timeout=1 +short +tcp @168.63.129.16
toomany100.ddstreet.org
;; connection timed out; no servers could be reached
;; Connection to
I spun up an azure instance and tested, and indeed tcp port 53 appears
completely missing from any tcpdump, but only for packets sent to the
upstream nameserver. TCP sent to port 53 on *any* other ip address does
make it out, but tcp port 53 to the nameserver does not. There are no
routing rules
Azure DNS does support DNS over TCP. Looking through a separate packet
capture I had taken during investigating this issue, I don't see any
attempts by resolved to open a TCP connection to port 53 of the DNS
server (in fact, I don't see any use of TCP port 53 at all).
Wireshark filters used:
Unfortunately, this is a bug in upstream systemd.
For some reason, resolved's current upstream code clamps the 'best'
server protocol level at 512-byte-sized EDNS0 if DNSSEC is disabled.
Since the default is for DNSSEC to be disabled, this means by default,
resolved will restrict its udp edns0
** Changed in: systemd (Ubuntu)
Status: Incomplete => Confirmed
--
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/1886128
Title:
systemd-resolved does not resolve
Thank you for the explanation, I have gathered dns.pcap file with the
required option.
** Attachment added: "dns (1).pcap"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1886128/+attachment/5391049/+files/dns%20%281%29.pcap
--
You received this bug notification because you are a
> dns.pcap Edit (14.5 KiB, application/vnd.tcpdump.pcap)
that's tcpdump output, not actually a pcap; to get an actual pcap use
the tcpdump -w parameter to write the packets to a file.
> Could you please advise how to increase UDP payload size for the local
stub resolver?
resolved adjusts levels
Thank you for the detailed explanation.
Let me clarify some things here:
1) In the initial reply, I provided two types of reponses:
- A successful one, that goes right through EDNS0 with UDP payload size 4096
- An unsuccessful one, that goes through the local stub resolver, but with udp
well that's not a pcap, a pcap is a packet capture, e.g. from tcpdump.
Your log shows your response is truncated:
Jul 08 07:27:22 ubuntu18oras systemd-resolved[963]: Got DNS stub UDP query
packet for id 2283
Jul 08 07:27:22 ubuntu18oras systemd-resolved[963]: Looking up RR for
Added log as attachment
** Attachment added: "pcap.log"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1886128/+attachment/5390800/+files/pcap.log
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in
> please note: after the first read, link will disappear
it's already gone (this is a public bug)
--
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/1886128
Title:
Thank you,
I have gathered required log as you mentioned:
Output of journalctl -b -u systemd-resolved --no-pager( please note: after the
first read, link will disappear )
https://file.io/2LcfbtNf
Output of dig:
dig mharder-formrec.cognitiveservices.azure.com
; <<>> DiG
> We are reffering to the local stub resolver
yes, i understand that, but i'm asking if you are talking about local
traffic TO the stub resolver, or traffic FROM the stub resolver to your
upstream nameserver.
If you have pcap showing the problem, please attach it.
If you're not sure what I'm
Thank you for the answer. We are reffering to the local stub resolver(
127.0.0.53 ). As a workaround we have created symbolic link:
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
However, with the local stub resolver is still not working.
--
You received this bug notification
Are you referring to edns0 from glibc to the local stub resolver, or
edns0 from systemd-resolved to the upstream nameserver?
I don't see any problem when i resolve the name on bionic:
$ lsb_release -c
Codename: bionic
$ dpkg -l systemd|grep systemd
ii systemd237-3ubuntu10.41
16 matches
Mail list logo
