Report information
The Basics
Id:
41441
Status:
resolved
Priority:
Medium/Medium
Queue:
bind9-public
People
Owner:
Nobody in particular
Requestors:
Cc:
AdminCc:
BugTracker
Version Fixed:
9.9.9, 9.9.9-S1, 9.10.4, 9.11.0
Version Found:
(no value)
Versions Affected:
(no value)
Versions Planned:
(no value)
Priority:
P1 High
Severity:
S2 Normal
CVSS Score:
(no value)
CVE ID:
(no value)
Component:
BIND Server
Area:
feature
Attachments
forward_first_empty_disable.patch forward_first_empty_disable_v2.patch
Dates
Created:Thu, 07 Jan 2016 06:37:00 -0500
Updated:Wed, 16 Aug 2017 19:27:07 -0400
Closed:Mon, 07 Mar 2016 18:13:11 -0500

This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

History
  Thu, 07 Jan 2016 06:37:00 -0500 Petr Spacek <pspacek@redhat.com> - Ticket created
Subject: auto-disable empty zones if forward 'first' is configured
Date: Thu, 7 Jan 2016 12:36:54 +0100
To: bind-suggest@isc.org
From: "Petr Spacek" <pspacek@redhat.com>

Hello, I would like to propose a change in BIND's behavior with respect to interaction between forward 'zones' and automatic empty zones: Currently the configure_view() in server.c disables/skips the automatic empty zones if there is a forward 'zone' with policy 'only'. /* * If we would forward this name don't add a * empty zone for it. */ result = dns_fwdtable_find(view->fwdtable, name, &forwarders); if (result == ISC_R_SUCCESS && forwarders->fwdpolicy == dns_fwdpolicy_only) continue; For me as a user, it is kind of confusing and inconvenient that empty zones are enabled even for dns_fwdpolicy_first, because it effectively means that forwarding is not working for automatic empty zones. Typically I have to manually disable empty zones when global forwarder (for root zone) is configured as traffic optimization measure, while full recursion is used as a fallback. In other words, the gotcha is that condition 'we would forward this name' is fulfilled also when forward policy 'first' is used. Would it be possible to relax the condition to forwarders->fwdpolicy != dns_fwdpolicy_none ? That would match my expectation as user - i.e. when I configure forwarding for all zones, it should be respected. I can see the potential problem with leaking queries when all configured forwarders fail, but given that this would happen only in a (hopefully rare) error state, I think it is a good trade-off for usability. If this is 'simple' fix is not acceptable, I can write a patch which would replace automatic empty zone with forward 'zone' with policy 'only' and addresses taken from parent forward zone with policy 'first', if you wish. Thank you for considering this. -- Petr Spacek @ Red Hat
forward_first_empty_disable.patch

Message body is not shown because sender requested not to inline it.

  Thu, 07 Jan 2016 09:11:51 -0500 Petr Spacek <pspacek@redhat.com> - Correspondence added
Subject: Re: [ISC-Bugs #41441] AutoReply: auto-disable empty zones if forward 'first' is configured
Date: Thu, 7 Jan 2016 15:11:42 +0100
To: bind-suggest@isc.org
From: "Petr Spacek" <pspacek@redhat.com>

On 7.1.2016 12:37, BIND Feature Requests via RT wrote: > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "auto-disable empty zones if forward 'first' is configured", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [ISC-Bugs #41441]. > > Please include the string: > > [ISC-Bugs #41441] > > in the subject line of all future correspondence about this issue. To do so, > you may reply to this message. > > Thank you, > bind-suggest@isc.org > > ------------------------------------------------------------------------- > Hello, > > I would like to propose a change in BIND's behavior with respect to > interaction between forward 'zones' and automatic empty zones: > > Currently the configure_view() in server.c disables/skips the automatic empty > zones if there is a forward 'zone' with policy 'only'. > > /* > * If we would forward this name don't add a > * empty zone for it. > */ > result = dns_fwdtable_find(view->fwdtable, name, > &forwarders); > if (result == ISC_R_SUCCESS && > forwarders->fwdpolicy == dns_fwdpolicy_only) > continue; > > For me as a user, it is kind of confusing and inconvenient that empty zones > are enabled even for dns_fwdpolicy_first, because it effectively means that > forwarding is not working for automatic empty zones. > > Typically I have to manually disable empty zones when global forwarder (for > root zone) is configured as traffic optimization measure, while full recursion > is used as a fallback. > > In other words, the gotcha is that condition 'we would forward this name' is > fulfilled also when forward policy 'first' is used. > > > Would it be possible to relax the condition to > forwarders->fwdpolicy != dns_fwdpolicy_none > ? > > That would match my expectation as user - i.e. when I configure forwarding for > all zones, it should be respected. > > > I can see the potential problem with leaking queries when all configured > forwarders fail, but given that this would happen only in a (hopefully rare) > error state, I think it is a good trade-off for usability. > > > If this is 'simple' fix is not acceptable, I can write a patch which would > replace automatic empty zone with forward 'zone' with policy 'only' and > addresses taken from parent forward zone with policy 'first', if you wish. > > > Thank you for considering this. I found out that the original version was not complete. Here is new version of the patch + test. -- Petr Spacek @ Red Hat
forward_first_empty_disable_v2.patch

Message body is not shown because sender requested not to inline it.

  Thu, 07 Jan 2016 12:43:16 -0500 Evan Hunt <each@isc.org> - Correspondence added
Subject: Re: [ISC-Bugs #41441] auto-disable empty zones if forward 'first' is configured
Date: Thu, 7 Jan 2016 17:43:16 +0000
To: "Petr Spacek via RT" <bind-suggest@isc.org>
From: "Evan Hunt" <each@isc.org>

Thank you Petr, we'll have a look at it. It's probably going to take a few days, we've all got our hands full at the moment.
Thu, 07 Jan 2016 12:43:17 -0500 The RT System itself - Status changed from 'new' to 'open'
  Mon, 11 Jan 2016 03:37:03 -0500 Petr Spacek <pspacek@redhat.com> - Correspondence added
Subject: Re: [ISC-Bugs #41441] auto-disable empty zones if forward 'first' is configured
Date: Mon, 11 Jan 2016 09:36:52 +0100
To: bind-suggest@isc.org
From: "Petr Spacek" <pspacek@redhat.com>

On 7.1.2016 18:43, Evan Hunt via RT wrote: > Thank you Petr, we'll have a look at it. It's probably going to take > a few days, we've all got our hands full at the moment. Sure, no problem. I've written a short design for the behavior I consider optimal. You can read it on: https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/AutomaticEmptyZones#Design I hope this helps to understand the intent. -- Petr Spacek @ Red Hat
Tue, 12 Jan 2016 11:02:28 -0500 Stephen Morris <stephen@isc.org> - Area feature added
Tue, 12 Jan 2016 11:02:28 -0500 Stephen Morris <stephen@isc.org> - Component BIND Server added
Wed, 13 Jan 2016 12:56:00 -0500 Stephen Morris <stephen@isc.org> - Priority P1 High added
Wed, 13 Jan 2016 12:56:00 -0500 Stephen Morris <stephen@isc.org> - Severity S3 Low added
  Sun, 17 Jan 2016 22:42:31 -0500 Mark Andrews <marka@isc.org> - Correspondence added

This allows queries to reach the Internet when the forwarder is down. The current behaviour is explicitly designed to prevent this. Yes, this requires people to think about what they are trying to achieve. "forward first;" is optimisation "forward only;" is grafting of namespace / server reachability. Note "forward" is almost always the wrong way to graft on namespace but somehow this is what people do rather than slaving the top of the private namespace. Mark
  Mon, 18 Jan 2016 06:17:15 -0500 Petr Spacek <pspacek@redhat.com> - Correspondence added
Subject: Re: [ISC-Bugs #41441] auto-disable empty zones if forward 'first' is configured
Date: Mon, 18 Jan 2016 12:17:10 +0100
To: bind-suggest@isc.org
From: "Petr Spacek" <pspacek@redhat.com>

On 18.1.2016 04:42, Mark Andrews via RT wrote: > This allows queries to reach the Internet when the forwarder is down. The > current behaviour is explicitly designed to prevent this. Yes, this requires > people to think about what they are trying to achieve. > > "forward first;" is optimisation "forward only;" is grafting of namespace / server > reachability. I see your point, Mark. What about a following approach? When an automatic empty zone is unloaded, it must be replaced with a new auto-generated "replacement" forward zone. The replacement forward zone will use IP addresses of the forwarders from the "conflicting"/"user-defined" forward zone and use policy = only. This will prevent BIND from leaking queries to the public Internet even if the user-defined forward policy != only and the forwarder fails. At the same time, I believe that it would be less error-prone from user's perspective. > Note "forward" is almost always the wrong way to graft on namespace but somehow > this is what people do rather than slaving the top of the private namespace. I agree, but unfortunately I do not see a way around user's unwillingness to change bad habits. Thank you for considering this. -- Petr Spacek @ Red Hat
  Mon, 18 Jan 2016 07:14:19 -0500 Mark Andrews <marka@isc.org> - Correspondence added
Subject: Re: [ISC-Bugs #41441] auto-disable empty zones if forward 'first' is configured
Date: Mon, 18 Jan 2016 23:14:09 +1100
To: bind-suggest@isc.org
From: "Mark Andrews" <marka@isc.org>

In message <rt-4.2.8-9765-1453115835-850.41441-4-0@isc.org>, "Petr Spacek via RT" writes: > On 18.1.2016 04:42, Mark Andrews via RT wrote: > > This allows queries to reach the Internet when the forwarder is down. The > > current behaviour is explicitly designed to prevent this. Yes, this requires > > people to think about what they are trying to achieve. > > > > "forward first;" is optimisation "forward only;" is grafting of namespace / server > > reachability. > > I see your point, Mark. What about a following approach? > > When an automatic empty zone is unloaded, it must be replaced with a new > auto-generated "replacement" forward zone. The replacement forward zone will > use IP addresses of the forwarders from the "conflicting"/"user-defined" > forward zone and use policy = only. and if you do that you will get servfail rather than nxdomain when the forwarders are down. > This will prevent BIND from leaking queries to the public Internet even if the > user-defined forward policy != only and the forwarder fails. > > At the same time, I believe that it would be less error-prone from user's > perspective. > > > Note "forward" is almost always the wrong way to graft on namespace but somehow > > this is what people do rather than slaving the top of the private namespace. > > I agree, but unfortunately I do not see a way around user's unwillingness to > change bad habits. > > > Thank you for considering this. > > -- > Petr Spacek @ Red Hat > > > > -- > Ticket History: https://bugs.isc.org/Ticket/Display.html?id=41441 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
  Mon, 18 Jan 2016 07:32:21 -0500 Petr Spacek <pspacek@redhat.com> - Correspondence added
Subject: Re: [ISC-Bugs #41441] auto-disable empty zones if forward 'first' is configured
Date: Mon, 18 Jan 2016 13:32:10 +0100
To: bind-suggest@isc.org
From: "Petr Spacek" <pspacek@redhat.com>

On 18.1.2016 13:14, Mark Andrews via RT wrote: > > In message <rt-4.2.8-9765-1453115835-850.41441-4-0@isc.org>, "Petr Spacek via RT" writes: >> On 18.1.2016 04:42, Mark Andrews via RT wrote: >>> This allows queries to reach the Internet when the forwarder is down. The >>> current behaviour is explicitly designed to prevent this. Yes, this requires >>> people to think about what they are trying to achieve. >>> >>> "forward first;" is optimisation "forward only;" is grafting of namespace / server >>> reachability. >> >> I see your point, Mark. What about a following approach? >> >> When an automatic empty zone is unloaded, it must be replaced with a new >> auto-generated "replacement" forward zone. The replacement forward zone will >> use IP addresses of the forwarders from the "conflicting"/"user-defined" >> forward zone and use policy = only. > > and if you do that you will get servfail rather than nxdomain when the > forwarders are down. Yes, that is correct. I believe that it is a good thing because there is no useful answer anyway. Of course, our user base is way smaller than yours, but it seems to me that users are more puzzled by unexpected NXDOMAIN than by SERVFAILs. Often I can see users claiming that NXDOMAIN is a caching issue and start to flush caches along the path, or even lowering max-cache-ttl, in a false hope that it would help (and never returning it back to original values, of course). Petr Spacek @ Red Hat >> This will prevent BIND from leaking queries to the public Internet even if the >> user-defined forward policy != only and the forwarder fails. >> >> At the same time, I believe that it would be less error-prone from user's >> perspective. >> >>> Note "forward" is almost always the wrong way to graft on namespace but somehow >>> this is what people do rather than slaving the top of the private namespace. >> >> I agree, but unfortunately I do not see a way around user's unwillingness to >> change bad habits. >> >> >> Thank you for considering this. >> >> -- >> Petr Spacek @ Red Hat
  Thu, 21 Jan 2016 16:52:06 -0500 Mark Andrews <marka@isc.org> - Correspondence added

Meant to send this as a reply On Mon Jan 18 15:56:13 2016, marka wrote: > We really can't second guess what the user wants. We could look at > issuing > a warning if rfc1918 && inherited(first) -> warning. > > e.g. > zone 1.0.10.in-addr.arpa { type forward; forwarders { … }; }; -> > warning > > zone 1.0.10.in-addr.arpa { type forward; forward first; forwarders { … > }; }; -> no warning > > "inherited 'forward first;' for rfc1918 zone '%s' - did you want > 'forward only;'? (use explicit 'forward first;' in zone declaration to > disable warning)" > > If you feel like coding this we can review it.
  Tue, 16 Feb 2016 07:53:42 -0500 Petr Spacek <pspacek@redhat.com> - Correspondence added
Subject: Re: [ISC-Bugs #41441] auto-disable empty zones if forward 'first' is configured
Date: Tue, 16 Feb 2016 13:53:37 +0100
To: bind-suggest@isc.org
From: "Petr Spacek" <pspacek@redhat.com>

On 21.1.2016 22:52, Mark Andrews via RT wrote: > Meant to send this as a reply > > On Mon Jan 18 15:56:13 2016, marka wrote: >> We really can't second guess what the user wants. We could look at >> issuing >> a warning if rfc1918 && inherited(first) -> warning. >> >> e.g. >> zone 1.0.10.in-addr.arpa { type forward; forwarders { … }; }; -> >> warning >> >> zone 1.0.10.in-addr.arpa { type forward; forward first; forwarders { … >> }; }; -> no warning >> >> "inherited 'forward first;' for rfc1918 zone '%s' - did you want >> 'forward only;'? (use explicit 'forward first;' in zone declaration to >> disable warning)" >> >> If you feel like coding this we can review it. I got lost in the configuration logic and I cannot see an obvious way how to do this. Would it be okay to always print a warning if policy == first and the zone is one of automatic empty zones? For me it is hard to imagine a case where it okay to use policy 'first' anyway. This reminds me one more thing regarding auto-disabling empty zones for policy == only. If the user defined forward zone 3.2.10.in-addr.arpa it unloads complete zone 10.in-addr.arpa. As a consequence, queries for rest of 10.in-addr.arpa will leak. Is this expected/okay? -- Petr Spacek @ Red Hat
Wed, 17 Feb 2016 00:04:29 -0500 Mark Andrews <marka@isc.org> - Queue changed from #3 to #7
  Wed, 17 Feb 2016 00:08:48 -0500 Mark Andrews <marka@isc.org> - Correspondence added

This is the way to check this. I've just coded this and submitted it for review with supporting changes. @@ -1969,6 +1975,32 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions, result = ISC_R_FAILURE; /* + * Check that a RFC 1918 / ULA reverse zone is not forward first + * unless explictly configured to be so. + */ + if (ztype == FORWARDZONE && (rfc1918 || ula)) { + obj = NULL; + (void)cfg_map_get(zoptions, "forward", &obj); + if (obj == NULL) { + /* + * Forward mode not explicity configured. + */ + if (voptions != NULL) + cfg_map_get(voptions, "forward", &obj); + if (obj == NULL && goptions != NULL) + cfg_map_get(goptions, "forward", &obj); + if (obj == NULL || + strcasecmp(cfg_obj_asstring(obj), "first") == 0) + cfg_obj_log(zconfig, logctx, ISC_LOG_WARNING, + "inherited 'forward first;' for " + "%s zone '%s' - did you want " + "'forward only;'?", + rfc1918 ? "rfc1918" : "ula", + znamestr); + } + } + + /* * Check validity of static stub server addresses. */ obj = NULL;
  Wed, 17 Feb 2016 08:54:10 -0500 Petr Spacek <pspacek@redhat.com> - Correspondence added
Subject: Re: [ISC-Bugs #41441] auto-disable empty zones if forward 'first' is configured
Date: Wed, 17 Feb 2016 14:54:03 +0100
To: bind9-review@isc.org
From: "Petr Spacek" <pspacek@redhat.com>

On 17.2.2016 06:08, Mark Andrews via RT wrote: > This is the way to check this. I've just coded this and submitted it for review with > supporting changes. > > @@ -1969,6 +1975,32 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t Oh, now it is clear. I did not realize that there is check_zoneconf() in lib/bind9/check.c. Thank you very much! -- Petr Spacek @ Red Hat
Mon, 07 Mar 2016 18:13:10 -0500 Mark Andrews <marka@isc.org> - Version Fixed 9.9.9,9.9.9(sub),9.10.4,9.11.0 added
Mon, 07 Mar 2016 18:13:11 -0500 Mark Andrews <marka@isc.org> - Status changed from 'open' to 'resolved'
Mon, 07 Mar 2016 18:13:11 -0500 Mark Andrews <marka@isc.org> - Queue changed from #7 to #30
Wed, 03 Aug 2016 15:50:38 -0400 Vicky Risk <vicky@isc.org> - Subject changed from 'auto-disable empty zones if forward 'first' is configured' to '[Patch[ auto-disable empty zones if forward 'first' is configured'
Wed, 03 Aug 2016 15:51:00 -0400 Vicky Risk <vicky@isc.org> - Severity S3 Low changed to S2 Normal
Wed, 21 Jun 2017 14:36:46 -0400 Brian Conry <bconry@isc.org> - Queue changed from #30 to #6
Fri, 07 Jul 2017 19:36:16 -0400 Vicky Risk <vicky@isc.org> - Queue changed from #6 to bind9-public
Wed, 16 Aug 2017 19:27:07 -0400 Mark Andrews <marka@isc.org> - Version Fixed 9.9.9,9.9.9(sub),9.10.4,9.11.0 changed to 9.9.9, 9.9.9-S1, 9.10.4, 9.11.0