Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Static-stub zones and forwarding

856 views
Skip to first unread message

Mark Picone

unread,
Aug 24, 2012, 1:45:22 AM8/24/12
to bind-...@lists.isc.org
Hi All,

I am in the process of migrating all of our client facing resolver hosts back to BIND (from unbound) and have hit a roadblock.
I wanted to confirm if I have missed something in my BIND configuration or I have hit some sort of limitation in BIND.

It appears as if BIND is ignoring the static-stub zone and just forwarding all queries to the specified forwarders.

The reason that I require a static-stub and not a forward zone is that our internal name servers have delegated zones (to Cisco GSS/F5 devices) which return site-specific answers; If I allow the client facing resolvers to recursively query the internal name servers I will get back the site-specific answer for the internal name server instead of the client facing resolver.
Using a static-stub zone forces the client facing resolver to use iterative queries which will eventually lead it to query the Cisco GSS/F5 device for itself.

Environment info:
- I have obscured hostnames & IP addresses.

Public facing name servers (host the 'external' view of our primary zone & also perform recursive lookups for our internal servers):
- 111.111.111.111
- 222.222.222.222

Internal facing name servers (host the 'internal' view of our primary zone, will perform recursive queries for client facing resolvers):
- 10.0.0.1
- 10.0.0.2
- 10.0.0.3

BIND/Unbound, (client facing resolver) details:

user@host:~ %cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.2 (Santiago)

user@host:~ %rpm -qa | grep ^bind
bind-9.8.2-0.10.rc1.el6_3.2.x86_64
bind-utils-9.8.2-0.10.rc1.el6_3.2.x86_64
bind-libs-9.8.2-0.10.rc1.el6_3.2.x86_64

user@host:~ %rpm -qa | grep unbound
unbound-1.4.14-1.el6.x86_64
unbound-libs-1.4.14-1.el6.x86_64


Unbound config (working):
- http://pastebin.com/MDFwZRLq
- Unbound sends iterative queries to the name servers specified in the stub zone.

BIND config #1 (static-stub zone ignored, all queries are forwarded to 111.111.111.111/222.222.222.222):
- http://pastebin.com/3rcZdxbQ

BIND config #2 (static-stub zone ignored, all queries are forwarded to 111.111.111.111/222.222.222.222):
- http://pastebin.com/cgbxSYph

Note: I have also tried setting 'forwards {};' in the static-stub zone but BIND returns with the error:
- "option 'forwarders' is not allowed in 'static-stub' zone 'obscured.edu.au'"


Regards,

Mark Picone
Unix Administrator
Deakin eSolutions

Deakin University
Geelong Waterfront Campus
1 Gheringhap Street, Geelong, VIC 3220
Phone: +61 3 52278602
Deakin University CRICOS Provider Code 00113B



Important Notice: The contents of this email are intended solely for the named addressee and are confidential; any unauthorised use, reproduction or storage of the contents is expressly prohibited. If you have received this email in error, please delete it and any attachments immediately and advise the sender by return email or telephone.

Deakin University does not warrant that this email and any attachments are error or virus free.

Mark Andrews

unread,
Aug 24, 2012, 1:58:08 AM8/24/12
to Mark Picone, bind-...@isc.org

This is partially addressed in the upcoming maintainence release.

diff --git a/lib/bind9/check.c b/lib/bind9/check.c
index 5d95eda..5891255 100644
--- a/lib/bind9/check.c
+++ b/lib/bind9/check.c
@@ -1324,8 +1324,10 @@ check_zoneconf(const cfg_obj_t *zconfig, const cfg_obj_t *voptions,
{ "also-notify", MASTERZONE | SLAVEZONE },
{ "dialup", MASTERZONE | SLAVEZONE | STUBZONE | STREDIRECTZONE },
{ "delegation-only", HINTZONE | STUBZONE | DELEGATIONZONE },
- { "forward", MASTERZONE | SLAVEZONE | STUBZONE | FORWARDZONE },
- { "forwarders", MASTERZONE | SLAVEZONE | STUBZONE | FORWARDZONE },
+ { "forward", MASTERZONE | SLAVEZONE | STUBZONE |
+ STATICSTUBZONE | FORWARDZONE },
+ { "forwarders", MASTERZONE | SLAVEZONE | STUBZONE |
+ STATICSTUBZONE | FORWARDZONE },
{ "maintain-ixfr-base", MASTERZONE | SLAVEZONE | STREDIRECTZONE },
{ "max-ixfr-log-size", MASTERZONE | SLAVEZONE | STREDIRECTZONE },
{ "notify-source", MASTERZONE | SLAVEZONE },

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Michael Hoskins (michoski)

unread,
Aug 24, 2012, 3:06:19 AM8/24/12
to Mark Picone, bind-...@lists.isc.org
-----Original Message-----

From: Mark Picone <mark....@deakin.edu.au>
Date: Thursday, August 23, 2012 10:45 PM
To: "bind-...@lists.isc.org" <bind-...@lists.isc.org>
Subject: Static-stub zones and forwarding

>Hi All,
>
>I am in the process of migrating all of our client facing resolver hosts
>back to BIND (from unbound) and have hit a roadblock.
>I wanted to confirm if I have missed something in my BIND configuration
>or I have hit some sort of limitation in BIND.
>
>It appears as if BIND is ignoring the static-stub zone and just
>forwarding all queries to the specified forwarders.
>
>The reason that I require a static-stub and not a forward zone is that
>our internal name servers have delegated zones (to Cisco GSS/F5 devices)
>which return site-specific answers; If I allow the client facing
>resolvers to recursively query the internal name servers I will get back
>the site-specific answer for the internal name server instead of the
>client facing resolver.
>Using a static-stub zone forces the client facing resolver to use
>iterative queries which will eventually lead it to query the Cisco GSS/F5
>device for itself.

Going out on a limb (we have something similar, but there might be small
implementation details that are different) -- have you tried making master
zones vs stubs, where you can use forwarders {}; to override the global
list, and then place NS delegations and glue pointing to the GSS/F5
devices?

Mark Picone

unread,
Aug 29, 2012, 10:09:26 PM8/29/12
to Mark Andrews, bind-...@isc.org
Hi Mark,

Thanks for the heads up; I have tested this patch in our environment and it fixes the problem for us :).

As we have Red Hat support, I have asked if they would include this patch early for us.

In the meantime, I'm considering just running a hand compiled version of 'named-checkconf' with our supported BIND package.

Regards,

Mark Picone
Unix Administrator
Deakin eSolutions

Deakin University
Geelong Waterfront Campus
1 Gheringhap Street, Geelong, VIC 3220
Phone: +61 3 52278602
Deakin University CRICOS Provider Code 00113B


0 new messages