2

This is a companion to an AskUbuntu question I posted before I had learned enough to ask this question.

(This is for Ubuntu 18.04)

By watching the debug output from systemd-resolved, I can do queries like:

host foo.mycompany.com

and see that what's happening is that systemd-resolved is deferring to my local DNS server (in my router) with a UDP query. That comes back with a response that convinces systemd to create a NODATA cache entry.

However, when I do:

host -a foo.mycompany.com

to request an ANY query, the debug output clearly indicates that the UDP response packet was truncated, so it falls back to a TCP query. When that returns, systemd apparently sees a valid address and creates a positive cache entry.

You can check the linked question, but the bottom line is that it makes some domain names only work (for a while) if I do a host -a lookup for the domain.

What I don't know is what it is that might be messed up that would cause this behavior. I don't think it has anything to do with systemd-resolved itself, because if I bypass that and go straight from my machine to the router DNS the results are the same (though I can't see the debug trace of course). I don't think my router is part of the problem, since a co-worker was able to see the same effect (and he's not in my house).

  • 1
    I'm starting to wonder if the difference might not be UDP vs TCP, but the query type ("A" vs "ANY") – Pointy May 1 at 17:57
  • Both probably. TCP serves longer answers and ANY brings more aditional glue to populate the DNS cache. – Rui F Ribeiro May 1 at 18:29
  • @RuiFRibeiro we're starting to think it has to do with caching servers being reluctant to return "private" IP addresses. That kind-of makes sense, though it's not clear why they're willing to do so for ANY queries. – Pointy May 1 at 18:34
  • 1
    @dirkt for simple queries, the local systemd server does get a response, but it's a negative response (basically "not found"), so the local server adds a NODATA record to its cache. With an ANY query, however, it does get a positive response with a good IP address. So the authoritative server is willing to return the 172.20 addresses, but intermediate caching servers (sometimes) are not. – Pointy May 2 at 14:42
  • 1
    @dirkt it's a security thing that I kind-of understand; it is intended to prevent those subnets from being hijacked by naughty people. – Pointy May 2 at 14:44
2

I think that we've determined that what's happening is some intermediate caching servers (for example, the server in my home router) are reluctant to return RFC1918 ("private") addresses. Thus the short queries that most software does (browsers etc) will leverage those caches, but the server returns what amounts to a "not found". The local systemd server therefore caches a NODATA entry because it thinks that's the right thing to do.

An ANY query isn't cached by intermediate servers, so the local server gets a response from the authoritative server.

Or something like that. I'll leave the question unanswered for now in case somebody who actually knows how these things work can explain better.

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.