1.9.2rc1 and x-zone CNAME

[Wouter Wijngaards]

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

On 6/9/19 11:44 AM, Harry Schmalzbauer via Unbound-users wrote:
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20190611/b3b44a9f/attachment.bin>