Irregular DNS lookup failures

Unbound
1

Hello,
We install unbound as a local caching DNS server on all our hosts. By doing this, we prevent our AD DNS servers from getting pounded by requests. It’s been working well for the most part. But on one host, sometimes unbound will not resolve a cname for a host which exists in another domain. Often DNS lookups work, but infrequently they don’t, just on this particular CNAME. I’m wondering why- can you give me any clues? I’ve added what I know, below. Let me know if I’ve missed anything. Thanks.

We have two domains. Let’s call them ouroffice.com and ouroffice.hk. The problem is on an Asian host. Here’s their /etc/resolv.conf; note that 10.20.80.12 and .13 are local DNS/AD servers:

domain [ouroffice.hk](http://ouroffice.hk)
search [ouroffice.hk](http://ouroffice.hk) [ouroffice.com](http://ouroffice.com)
nameserver 127.0.0.1
nameserver 10.20.80.12
nameserver 10.20.80.13
# failover control
options timeout:2 attempts:2

I have logging turned up on unbound and here is what a successful query looks like:

2021-10-20T03:30:50.341449+08:00 host1shortname unbound: [43588:0] info: resolving Some-file_transfer_server.ouroffice.hk. A IN
2021-10-20T03:30:50.341466+08:00 host1shortname unbound: [43588:0] info: use stub ouroffice.hk. NS IN
2021-10-20T03:30:50.341470+08:00 host1shortname unbound: [43588:0] info: use stub ouroffice.hk. NS IN
2021-10-20T03:30:50.341765+08:00 host1shortname unbound: [43588:0] info: response for Some-file_transfer_server.ouroffice.hk. A IN
2021-10-20T03:30:50.341773+08:00 host1shortname unbound: [43588:0] info: reply from <ouroffice.hk.> 10.20.80.13#53
2021-10-20T03:30:50.341777+08:00 host1shortname unbound: [43588:0] info: query response was CNAME
2021-10-20T03:30:50.341789+08:00 host1shortname unbound: [43588:0] info: resolving Some-file_transfer_server.ouroffice.hk. A IN
2021-10-20T03:30:50.341951+08:00 host1shortname unbound: [43588:0] info: response for Some-file_transfer_server.ouroffice.hk. A IN
2021-10-20T03:30:50.341956+08:00 host1shortname unbound: [43588:0] info: reply from <.> 10.20.80.13#53
2021-10-20T03:30:50.341959+08:00 host1shortname unbound: [43588:0] info: query response was NXDOMAIN ANSWER
2021-10-20T03:30:50.342138+08:00 host1shortname unbound: [43588:0] info: resolving Some-file_transfer_server.ouroffice.com. A IN
2021-10-20T03:30:50.342268+08:00 host1shortname unbound: [43588:0] info: response for Some-file_transfer_server.ouroffice.com. A IN
2021-10-20T03:30:50.342273+08:00 host1shortname unbound: [43588:0] info: reply from <.> 10.20.80.13#53
2021-10-20T03:30:50.342276+08:00 host1shortname unbound: [43588:0] info: query response was CNAME
2021-10-20T03:30:50.342281+08:00 host1shortname unbound: [43588:0] info: resolving Some-file_transfer_server.ouroffice.com. A IN
2021-10-20T03:30:50.342421+08:00 host1shortname unbound: [43588:0] info: response for Some-file_transfer_server.ouroffice.com. A IN
2021-10-20T03:30:50.342428+08:00 host1shortname unbound: [43588:0] info: reply from <.> 10.20.80.12#53
2021-10-20T03:30:50.342432+08:00 host1shortname unbound: [43588:0] info: query response was ANSWER
2021-10-20T03:30:50.342646+08:00 host1shortname unbound: [43588:0] info: resolving ahost2.ouroffice.com. AAAA IN
2021-10-20T03:30:50.342768+08:00 host1shortname unbound: [43588:0] info: response for ahost2.ouroffice.com. AAAA IN
2021-10-20T03:30:50.342774+08:00 host1shortname unbound: [43588:0] info: reply from <.> 10.20.80.12#53
2021-10-20T03:30:50.342777+08:00 host1shortname unbound: [43588:0] info: query response was nodata ANSWER
2021-10-20T03:30:50.342852+08:00 host1shortname unbound: [43588:0] info: resolving ahost2.ouroffice.com. MX IN
2021-10-20T03:30:50.342940+08:00 host1shortname unbound: [43588:0] info: response for ahost2.ouroffice.com. MX IN
2021-10-20T03:30:50.342945+08:00 host1shortname unbound: [43588:0] info: reply from <.> 10.20.80.12#53
2021-10-20T03:30:50.342947+08:00 host1shortname unbound: [43588:0] info: query response was nodata ANSWER

Here is a failed lookup:

2021-10-20T21:23:06.724658+08:00 host1shortname unbound: [43588:0] info: resolving Some-file_transfer_server.ouroffice.hk. A IN
2021-10-20T21:23:06.724669+08:00 host1shortname unbound: [43588:0] info: use stub ouroffice.hk. NS IN
2021-10-20T21:23:06.724673+08:00 host1shortname unbound: [43588:0] info: use stub ouroffice.hk. NS IN
2021-10-20T21:23:06.724994+08:00 host1shortname unbound: [43588:0] info: response for Some-file_transfer_server.ouroffice.hk. A IN
2021-10-20T21:23:06.725002+08:00 host1shortname unbound: [43588:0] info: reply from <ouroffice.hk.> 10.20.80.13#53
2021-10-20T21:23:06.725005+08:00 host1shortname unbound: [43588:0] info: query response was CNAME
2021-10-20T21:23:06.725012+08:00 host1shortname unbound: [43588:0] info: resolving Some-file_transfer_server.ouroffice.hk. A IN
2021-10-20T21:23:06.725174+08:00 host1shortname unbound: [43588:0] info: response for Some-file_transfer_server.ouroffice.hk. A IN
2021-10-20T21:23:06.725185+08:00 host1shortname unbound: [43588:0] info: reply from <.> 10.20.80.12#53
2021-10-20T21:23:06.725188+08:00 host1shortname unbound: [43588:0] info: query response was NXDOMAIN ANSWER

Here is our unbound.conf:

2

Hello,
We install unbound as a local caching DNS server on all our
hosts. By doing this, we prevent our AD DNS servers from
getting pounded by requests. It's been working well for the
most part. But on one host, sometimes unbound will not resolve
a cname for a host which exists in another domain. Often DNS
lookups work, but infrequently they don't, just on this
particular CNAME. I'm wondering why- can you give me any clues?
I've added what I know, below. Let me know if I've missed
anything. Thanks.

There is a possibility that what you experience doesn't really
have anything to do with unbound per se. The error might as well
lie on the publication side of things. E.g. are all the
publication servers for the zone in question supplying the same
answers to the given questions?

By you having obfuscated the logging output, there is however no
possibility for any of us to reproduce the problem.

There's also the possibility that you are operating with a "split
horizon" DNS setup on the publication side, so us knowing the
domain name in question wouldn't necessarily be of any help,
since the answer you get might depend on where the query is sent
from.

So... Not much we can do to help at the presen stage, I'm
afraid.

Regards,

- Håvard