0

I have a query which I'm struggling to get a precise answer for. I'm aware I can workaround the question by providing a different route for systemd-resolved, however I'm specifically wanting to know why in this setup, it works this way.

Question

Why does systemd-resolved work for .local addresses when going via CoreDNS via it's Kubernetes module, but not via the host module? What is happening for test #1 below to work? I don't think mDNS is being responded to by CoreDNS, there is module for mDNS howevr that's not configured.

It's normal for .local addresses to not work via systemd-resolved as the resolution occurs over mDNS - so why is test #1 working?

Setup

OS release = VMware Python 4.0

DNS setup = Using default symlink of /etc/resolv.conf > /run/systemd/resolve/stub-resolv.conf, name server is the default stub resolver, 127.0.0.53

resolvectl config = Only DNS server is 10.254.24.4 which is a CoreDNS pod running on Kubernetes. My dig commands are ran from a K8 node in the cluster. CoreDNS has the following config. There is a custom host entry in there which I'm using as part of the exercise to ask the question.

 Corefile: |
    . {
        bind 10.254.24.4 10.254.24.2 10.254.24.3
        log
        errors
        health 127.0.0.1:8082
        hosts {
           55.55.55.55 test.me.local
           fallthrough
        }
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        forward . 10.254.12.8 10.254.142.8
        cache 30
        loop
        reload
        loadbalance
    }

Now here comes the behaviour which I dont get. I understand that systemd-resolved will not work with .local domains. But look it does, see below

Test #1

Dig attempt of a .local address within Kubernetes, via stub 127.0.0.53, via 10.254.24.4. Gives an expected address

dig kubernetes.default.svc.cluster.local +noall +answer kubernetes.default.svc.cluster.local. 5 IN A 10.96.0.1

Test #2

Dig attempt direct to the name server, bypassing systemd-resolved, gives same result

dig kubernetes.default.svc.cluster.local +noall +answer @10.254.24.4 kubernetes.default.svc.cluster.local. 5 IN A 10.96.0.1

Test #3

Dig attempt direct to the name server, bypassing systemd-resolved, however for the manual A record added into CoreDNS. Gives expected result.

dig test.me.local +noall +answer @10.254.24.4 test.me.local. 30 IN A 55.55.55.55

Test #3

Dig attempt to the same test.me.local address via stub 127.0.0.53, via 10.254.24.4. Gives no result

dig test.me.local +noall +answer -- BLANK RESPONSE --

agill
  • 1

0 Answers0