1.9.2rc1 and x-zone CNAME

Unbound
1

Hello,

thank you very much for all the hard work improving unbound.

I tested various failover fixes briefly. But I have another show stopper for my usecase:

You have two auth-zone:, sample1.test and sample2.test (or sub.sample1.test or sample1.invalid, doesn't matter)
If your master has a CNAME RR, referencing a different zone with the same SOA, there's a "deadlock" with unbound; the CNAME will never get resolved, but only returning the CNAME.

How to repeat:
Create RR www.sample1.test. IN CNAME www.sample2.test.

drill @hiddenprimary www.sample1.test

;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 16083
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.sample1.test. IN A

;; ANSWER SECTION:
www.sample1.test. 1800 IN CNAME www.sample2.test.
www.sample2.test. 36000 IN CNAME s1.sample2.test.
s1.sample2.test. 36000 IN A 192.0.2.254

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

Now check that unbound correctly loaded the zones from the hidden primary and repeat the query against unbound instead of the hidden primary and the CNAME will never get resolved:

drill @localhost www.sample1.test
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 51266
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; www.sample1.test. IN A

;; ANSWER SECTION:
www.sample1.test. 1800 IN CNAME www.sample2.test.

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

I tried with transparent zones but never got x-zone CNAME records to work with unbound.
While here, why are answers for zones coming from local-zone: (SOA) not aa flagged?

Thanks,

-harry

2

Hi Harry,

The issue looks that you have the for-downstream: yes on both zones.
Unbound therefore uses that zone to answer downstream, and skipping to
another zone is not really what an authoritative server has to do as it
is outside of bailiwick in the answer. Even though other authoritative
server software can do so, in an (admittedly) probably wrong feature to
complete the cname chain even though the querier should not use that
part of the answer for safety reasons.

If you set for-downstream: no and for-upstream: yes on them, unbound can
use the content of the zones to recursively resolve the CNAME, and
complete the CNAME chain for you.

So, I think you set it to reply straight from that zone, but if you set
it to use the recursion processing on the zone contents, unbound can
complete the CNAME chain.

Best regards, Wouter

3

Does unbound set RA=0 on its replies in this case?

Tony.

4

Hello,

thanks for explanation and the hint.
I guess that's the problem, which breaks real world setup. Answer section contains RecursionAvailable flag.
So the client doesn't do any further lookup, hence the "dead" lookup.

It's out of my scope to suggest an fix.
But I can tell that even queries without RD are recursed and RA flagged by other servers (MS, ISC) for x-auth-zone CNAME records.
And that seems to be what clients rely on...
And unfortunately limits the usage of unbound as frontend to a hidden primary.
Ideas how this can be resolved?

Thanks,

-harry

5

Hi Harry,

The issue looks that you have the for-downstream: yes on both zones.
Unbound therefore uses that zone to answer downstream, and skipping to
another zone is not really what an authoritative server has to do as it
is outside of bailiwick in the answer.

Does unbound set RA=0 on its replies in this case?

Hello,

thanks for explanation and the hint.
I guess that's the problem, which breaks real world setup. Answer
section contains RecursionAvailable flag.
So the client doesn't do any further lookup, hence the "dead" lookup.

There is a client that depends on the RA flag for recursion or not for
lookups?

It's out of my scope to suggest an fix.
But I can tell that even queries without RD are recursed and RA flagged
by other servers (MS, ISC) for x-auth-zone CNAME records.
And that seems to be what clients rely on...
And unfortunately limits the usage of unbound as frontend to a hidden
primary.
Ideas how this can be resolved?

Why is it that you could not do the suggested config file fix? Set for
both zones in unbound.conf for-downstream: no and for-upstream: yes and
then unbound provides recursion for these zones?

Best regards, Wouter

6

…

But I can tell that even queries without RD are recursed and RA flagged
by other servers (MS, ISC) for x-auth-zone CNAME records.
And that seems to be what clients rely on...
And unfortunately limits the usage of unbound as frontend to a hidden
primary.
Ideas how this can be resolved?

Why is it that you could not do the suggested config file fix? Set for
both zones in unbound.conf for-downstream: no and for-upstream: yes and
then unbound provides recursion for these zones?

Hello Wouter,

this leads to the reply:
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 37468
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; test.sample1.local. IN A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
. 8 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2019061100 1800 900 604800 86400

;; ADDITIONAL SECTION:

;; Query time: 1 msec

This is no answer clients can hanlde.
Unfortunately, I didn't get the idea of for-downstream:no.
Which client would want a root hint?
Maybe there's something else wrong with my setup?

Thanks,

-harry

7

Hi Harry,

…

But I can tell that even queries without RD are recursed and RA flagged
by other servers (MS, ISC) for x-auth-zone CNAME records.
And that seems to be what clients rely on...
And unfortunately limits the usage of unbound as frontend to a hidden
primary.
Ideas how this can be resolved?

Why is it that you could not do the suggested config file fix? Set for
both zones in unbound.conf for-downstream: no and for-upstream: yes and
then unbound provides recursion for these zones?

Hello Wouter,

this leads to the reply:
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 37468
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; test.sample1.local. IN A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
. 8 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2019061100 1800 900 604800 86400

;; ADDITIONAL SECTION:

;; Query time: 1 msec

This is no answer clients can hanlde.
Unfortunately, I didn't get the idea of for-downstream:no.
Which client would want a root hint?
Maybe there's something else wrong with my setup?

Did you set for-upstream: yes ?

It seems to give an answer from the root zone instead of the authority
zone, but I thought it would have used the authority zone.

Best regards, Wouter

8

Hi Harry,

Hi Harry,

…

But I can tell that even queries without RD are recursed and RA flagged
by other servers (MS, ISC) for x-auth-zone CNAME records.
And that seems to be what clients rely on...
And unfortunately limits the usage of unbound as frontend to a hidden
primary.
Ideas how this can be resolved?

Why is it that you could not do the suggested config file fix? Set for
both zones in unbound.conf for-downstream: no and for-upstream: yes and
then unbound provides recursion for these zones?

Hello Wouter,

this leads to the reply:
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 37468
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; test.sample1.local. IN A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
. 8 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2019061100 1800 900 604800 86400

;; ADDITIONAL SECTION:

;; Query time: 1 msec

This is no answer clients can hanlde.
Unfortunately, I didn't get the idea of for-downstream:no.
Which client would want a root hint?
Maybe there's something else wrong with my setup?

Did you set for-upstream: yes ?

It seems to give an answer from the root zone instead of the authority
zone, but I thought it would have used the authority zone.

To answer myself, do you have a forward-zone? For me it then works if a
stub-zone exists (above the name). So, two entries of stub-zone: name:
"sample1.local" and stub-zone: name: "sample2.local" would make it work
for me. The issue is that unbound with a forward-zone, does not think
that it should perform recursion so getting data from the authority zone
is not what it wants, because the upstream recursor is doing the recursion.

Best regards, Wouter

9

Hello Wouter,

thanks for the quick reply! I do have for-upstream: yes in my config.
I always wondered why for-upstream: yes and for-downstream: no only results in root zone hint.
As soon as I set for-downstream: yes, I get the expected answers with aa flag from the corresponding zone, but like mentioned with the CNAME problem.
Is unbound with setting for-downstream: no supposed to reply with an answer from zone?

Thanks,

-harry

10

…

Why is it that you could not do the suggested config file fix? Set for
both zones in unbound.conf for-downstream: no and for-upstream: yes and
then unbound provides recursion for these zones?

Hello Wouter,

this leads to the reply:
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 37468
;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;; test.sample1.local. IN A

;; ANSWER SECTION:

;; AUTHORITY SECTION:
. 8 IN SOA a.root-servers.net.
nstld.verisign-grs.com. 2019061100 1800 900 604800 86400

;; ADDITIONAL SECTION:

;; Query time: 1 msec

This is no answer clients can hanlde.
Unfortunately, I didn't get the idea of for-downstream:no.
Which client would want a root hint?
Maybe there's something else wrong with my setup?

Did you set for-upstream: yes ?

It seems to give an answer from the root zone instead of the authority
zone, but I thought it would have used the authority zone.

To answer myself, do you have a forward-zone? For me it then works if a
stub-zone exists (above the name). So, two entries of stub-zone: name:
"sample1.local" and stub-zone: name: "sample2.local" would make it work
for me. The issue is that unbound with a forward-zone, does not think
that it should perform recursion so getting data from the authority zone
is not what it wants, because the upstream recursor is doing the recursion.

Hi Wouter,

thanks a lot for that hint.
I always had forwarding "." defined, nice catch – it never came to my mind that this could cause "for-downstream: no"-anomalies; and newer asked if the reply I've been wondering about ever since is correct...

So with forwarder defined and auth-zone: in place, one has to set "for-downstream: no" and _additionally_ define stub-zone: for the same auth-zone: names !?
Will try that next time, thanks!

-Harry

11

I had a test setup available, so I tried and I can confirm that the addtitional stub-zone: definition leads to correct replies from auth-zone: when forwad-zone: "." is defined.
But, when I set "for-downstream: no" (in order to get CNAME records resolved) the replies don't have AA set.
Some MS mechanism needs authoritative answers to determine correct ActiveDirectory "location".
_And_ I'd need x-zone CNAME working, which is not possible as far as I understand.
Please correct me if I'm wrong.

Thanks,

-harry