Project

General

Profile

Actions

Bug #6065

closed

unbound: Domain Overrides are not always working if using stub-zones

Added by Grischa Zengel over 8 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
DNS Resolver
Target version:
Start date:
04/02/2016
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:

Description

The most time Domain Overrides are used for private networks:
  1. The used DNS servers are not authoritative
  2. The authoritative DNS Servers are in not reachable subnets so recursive queries are not possible

I found this https://wiki.archlinux.org/index.php/Unbound:

Note: There is a difference between forward zones and stub zones - stub zones will only work when connected to an authoritative DNS server directly. This would work for lookups from a BIND DNS server if it is providing authoritative DNS - but if you are referring queries to an unbound server in which internal lookups are forwarded on to another DNS server, then defining the referral as a stub zone in the machine here will not work. In that case it is necessary to define a forward zone as above, since forward zones can have daisy chain lookups onward to other DNS servers. i.e. forward zones can refer queries to recursive DNS servers. This distinction is important as you do not get any error messages indicating what the problem is if you use a stub zone inappropriately.

  1. Use domain-insecure if DNSSEC is enabled
  2. Use forward-zone instead of stub-zone
  3. I have learned to put a point after FQDN

This works very well:

domain-insecure: "extern1.local." 
domain-insecure: "hq1.local." 
domain-insecure: "hq2.local." 
forward-zone:
        name: "extern1.local." 
        forward-addr: 10.190.0.1
forward-zone:
        name: "hq1.local." 
        forward-addr: 10.190.0.1
forward-zone:
        name: "hq2.local." 
        forward-addr: 10.190.0.1

Actions

Also available in: Atom PDF