Hi Joe, On 05/02/18 14:05, Joe via Unbound-users wrote: > Hi list > > I have a stub-zone entry like the following: > stub-zone: > name: "office.intra" > stub-addr: 10.0.0.1 > stub-addr: 10.0.0.2 > > This works great except for CNAME entries, where I get the CNAME but not > the A Record. > > $ dig test.office.intra > ... > ;; ANSWER SECTION: > test.office.intra. 3494 IN CNAME test.manage.intra. > > ;; AUTHORITY SECTION: > . 3494 IN SOA a.root-servers.net. > nstld.verisign-grs.com. 2018020500 1800 900 604800 86400 > > > The manage.intra zone is configured as local-zone on unbound. > I am able to query the manage.intra zone: > > $ dig test.manage.intra. > ;; ANSWER SECTION: > test.manage.intra. 60 IN A 10.1.0.99 > > What am I missing?
Unbound works by first checking local-zones, then cache, then performing recursive lookup, that recursive lookup then uses the cache and sends queries to upstream authority servers. The localzones are a filter in front of all other stuff that unbound does. Unbound wants to lookup manage.intra at the back, so it needs a forward-zone or a stub-zone for that, somewhere where it can find the information in manage.intra. With (not yet released) authority zones you can do this, and configure unbound to use that authority zone data as a proxy for upstream queries. Instead of sending queries to upstream servers, it'll use that authority data directly. I.e. it'll sit at the back, instead of as local-zones at the front. There is also an option to put auth-zones at the front. And another one to failover to normal internet queries on validation failures (for RFC7706 root zone copies). If enabled as a proxy for upstream queries, unbound would use it to answer queries there but also CNAMEs pointing there. Best regards, Wouter > > Best regards and thanks > Joe
Description: OpenPGP digital signature