You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We don't have any issues resolving AWS domain or Consul domain, the issue is only related to reverse lookup. We are occasionally seeing instance resolves it's FQDN with Consul domain.
Example of the same dig command running within few seconds interval:
Global
DNS Servers: 127.0.0.1
DNS Domain: ~consul
DNSSEC NTA: 10.in-addr.arpa
16.172.in-addr.arpa
168.192.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
corp
d.f.ip6.arpa
home
internal
intranet
lan
local
private
test
Link 2 (eth0)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: 172.31.0.2
DNS Domain: us-east-1.compute.internal
This is (I think) the opposite of what you're trying to do (100% of PTR lookups resolve to .consul) but it might show you another path. Also take note of my comment on #4155 about the iptables rule being the only reason you need to run on 127.0.0.2. If you follow the link in #4155, you'll find where the rules are being persisted for reboots.
Overview of the Issue
We are running Consul server on Ubuntu 18.04 in AWS. Systemd-resolved setup was followed from this guid: https://learn.hashicorp.com/consul/security-networking/forwarding#systemd-resolved-setup
We don't have any issues resolving AWS domain or Consul domain, the issue is only related to reverse lookup. We are occasionally seeing instance resolves it's FQDN with Consul domain.
Example of the same dig command running within few seconds interval:
ip-172-31-28-9:~$ dig -x 172.31.28.9
ip-172-31-28-9:~$ dig -x 172.31.28.9
Same thing happens when trying to get FQDN in python using socket.getfqdn():
Config
/etc/resolv.conf
/etc/systemd/resolved.conf.d/10-consul.conf
/etc/consul.d/agent/config.json
systemd-resolve --status
/etc/iptables/rules.v4
Reproduction Steps
OS: Ubuntu 18.04
Infrastructure: AWS EC2 instance with default DNS
Systemd-resolved and Iptables setup from the guid: https://learn.hashicorp.com/consul/security-networking/forwarding#systemd-resolved-setup
Run
dig -x your_ip_address +short
in a loop (when running it 100 times we were getting ~10 names resolved with Consul domain)OR
Use python socket.getfqdn() to get FQDN
Consul info for both Client and Server
Client info
Server info
Operating system and Environment details
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=18.04
DISTRIB_CODENAME=bionic
DISTRIB_DESCRIPTION="Ubuntu 18.04.1 LTS"
systemd --version
systemd 237
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid
AWS instance with default DNS.
Log Fragments
ip-172-31-28-9:~$ dig -x 172.31.28.9
ip-172-31-28-9:~$ dig -x 172.31.28.9
The text was updated successfully, but these errors were encountered: