0

I have a server connected to my LAN and the Internet that I am unable to connect to using its FQDN. Let's say the FQDN is server.com.

For whatever reason I have not been able to get to the bottom of, resolution of server.com on my development machine (locally on the LAN) always results in ::1.

Here is the result of running host -v server.com:

Trying "server.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39898
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;server.com.            IN  A

;; ANSWER SECTION:
server.com.     6826    IN  A   192.168.0.2

Received 47 bytes from 127.0.0.53#53 in 0 ms
Trying "server.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16204
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;server.com.            IN  AAAA

;; ANSWER SECTION:
server.com.     6826    IN  AAAA    ::1

Received 59 bytes from 127.0.0.53#53 in 0 ms
Trying "server.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48845
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;server.com.            IN  MX

Received 31 bytes from 127.0.0.53#53 in 0 ms

Notice the answer to the second question above.

systemd-resolve actually produces the correct answer:

$ systemd-resolve server.com
server.com: 192.168.0.2

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

I have tried to restart systemd-resolved as well as --flush-caches but to no avail.

/etc/resolv.conf contains the following:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53
search server.com

The DNS resolution is as given (resolution is served by server.com): $ nmcli device show enp0s31f6 | grep -n2 IP4.DNS 10-IP4.GATEWAY: 192.168.0.1 11-IP4.ROUTE[1]: dst = 169.254.0.0/16, nh = 0.0.0.0, mt = 1000 12:IP4.DNS[1]: 192.168.0.2 13-IP4.DOMAIN[1]: server.com 14-IP6.ADDRESS[1]: fe80::9e5c:8eff:fe86:f30b/64

Finally, systemd-resolve --status produces the following:

Global
          DNS Domain: server.com
          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 (enp0s31f6)
      Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no
         DNS Servers: 192.168.0.2
          DNS Domain: server.com

I should probably mention that the following services are active on the server (server.com): DHCP, DNS (bind9, IIRC), SSH, HTTP(s); it acts as the DNS resolver for all machines on the LAN. Lastly, I'm aware I could simply add an entry in /etc/hosts and be done with it but I would really like to understand what's wrong as it may be a symptom of something more serious with the.

How can I diagnose what's going on?

  • 1
    Do you know what DNS server is being used on the machine that host is being run on? It sounds like it's querying its DNS server and perhaps that DNS server is authoritative and providing the wrong zone. (Real life examples of this, however, would be prudent, if possible, because you're basically talking hypothetically the way this is currently worded) – Thomas Ward Mar 9 '18 at 17:43
  • @ThomasWard: this is not hypothetical; it's very much real. Unfortunately I cannot reveal the real server FQDN for legal reasons. I've edited the post with additional info that I think answers your question? – miguelg Mar 9 '18 at 17:54
  • 1
    Real or not, you missed the point of that statement. And no, that doesn't answer what I"m after. What I'm seeing there is it's handing to systemd-resolve which has a local component. I'm looking for the servers that systemd-resolve is trying to reach out to for resolutions - is it checking a local bind9 instance on the same server or querying some other DNS server? – Thomas Ward Mar 9 '18 at 18:09
0

I solved this by querying the server's DNS records, which produced the following:

$ host server.com
server.com has address 192.168.0.2
server.com has IPv6 address ::1

Inspecting the contents of bind9's db.server.com configuration file revealed a sneaky IPv6 entry:

@       IN  AAAA    ::1

Disabling the above and restarting bind9, solved it.

Thanks to Thomas Ward for comments that allowed me to approach this differently and eventually fix it.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.