Bug 32791 - Konfiguration des root-zone-type per UCR
Konfiguration des root-zone-type per UCR
Status: RESOLVED WONTFIX
Product: UCS
Classification: Unclassified
Component: DNS
UCS 4.2
Other Linux
: P5 enhancement (vote)
: ---
Assigned To: UCS maintainers
:
Depends on: 26301
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-02 13:09 CEST by Tim Petersen
Modified: 2020-07-03 20:53 CEST (History)
6 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number: 2013100121001389
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tim Petersen univentionstaff 2013-10-02 13:09:10 CEST
+++ This bug was initially created as a clone of Bug #26301 +++

In einer Kundenumgebung musste die root-Zone "." von "forward" auf "hint" umkonfiguriert werden (die root-Server sind nicht erreichbar, es gibt keinen forwarder).

Das sollte per UCR möglich sein.
##############


At ticket #2013100121001389 it was requested, that if dns/fakeroot is set to False the zone successfully changes to "type hint", but no fake rootzone will be used -> /etc/bind/db.root.fake

The customer wanted to configure:
type hint
file "/etc/bind/db.root.fake";

Instead by setting dns/fakeroot=False it gets:
type hint;
file "/etc/bind/db.root";
Comment 1 Stefan Gohmann univentionstaff 2013-10-10 12:35:45 CEST
(In reply to Tim Petersen from comment #0)
> At ticket #2013100121001389 it was requested, that if dns/fakeroot is set to
> False the zone successfully changes to "type hint", but no fake rootzone
> will be used -> /etc/bind/db.root.fake
> 
> The customer wanted to configure:
> type hint
> file "/etc/bind/db.root.fake";
> 
> Instead by setting dns/fakeroot=False it gets:
> type hint;
> file "/etc/bind/db.root";

As workaround / solution the db.root file can be moved with dpkg-divert and /etc/bind/db.root.fake can be copied to /etc/bind/db.root.
Comment 2 Stephan Hendl 2014-01-22 18:36:29 CET
Well, IMHO the dpkg-divert attempt does not lead to a good solution. Since we are totally behind a set of firewalls and are neither able to reach any of the root name servers nor to resolve any internet names. Every external traffic has to pass a proxy. Therefore we need an entry in the /etc/bind/named.conf.samba4 configured like below. 

zone "." {
        type hint;
        file "/etc/bind/db.root.fake";
};

I introduce a new ucs-variable "dns/fakeroothint" (in addition to "dns/fakeroot"). When this variable is set the template should lead to the above configuration.
Comment 3 Philipp Hahn univentionstaff 2014-01-23 11:05:16 CET
It looks like there's a change with newer versions of BIND9:

The problem is that BIND9 refused to load the empty root.zone.fake file when type=master:
> named[3112]: reloading configuration succeeded
> named[3112]: zone ./IN: has 0 SOA records
> named[3112]: zone ./IN: has no NS records
> named[3112]: zone ./IN: not loaded due to errors.
> named[3112]: reloading zones succeeded

So BIND9 only works again because then BIND9 falls back to its internal list of root-name-servers and can thus uses recursive queries. So that configuration is definitely broken.


With type=hint "rndc reload" produces the following warning, but a restart actually loads the empty file successfully:
> named[3112]: zone ./IN: (master) removed

But even then the forward-statement-delegations from the named.conf file are not processes. Using forward-statements only work with recursive-query, which always starts at the DNS root, so the query stops there because BIND9 does not know any root server at all and doesn't do a middle-in start using its forward zones as additional entry points.

It looks like that if you don't want to use the default root servers, you must define your own root-zone (as a master zone), which then delegates the allowed zones to your DNS servers.

PS: This is my current understanding; comments and corrections are appreciated.

<http://www.zytrax.com/books/dns/ch4/>
<http://www.zytrax.com/books/dns/ch7/zone.html#type>
Comment 4 Stefan Gohmann univentionstaff 2017-06-16 20:39:41 CEST
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4.

If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
Comment 5 Ingo Steuwer univentionstaff 2020-07-03 20:53:28 CEST
This issue has been filed against UCS 4.2.

UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed.

If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.