Moving from "type forward" to "type static-stub"

[Oscar Ricardo Silva]

I have several recursive, caching BIND servers that were running the
Redhat package of BIND. Our servers started crashing because of a bug
(previously identified AND fixed by ISC) so we've decided to ditch that
version and run from source, 9.9.1-P3. (I'm still not sure why redhat
decided to use the rc1 version of source on which to build their rpm ...
seriously ... the bug that hit us was fixed in rc2 AND the final release)


The current servers are configured to forward any queries for our domain
straight to our authoritative servers:

zone "utexas.org" IN {
type forward;
forwarders {
128.83.185.39;
129.116.136.5;
};
};




I've been reading about the new zone type: static-stub and believe
this may work better for us.

zone "utexas.org" IN {
type static-stub;
server-addresses {
128.83.185.39;
129.116.136.5;
};
};



If I'm correct, it will send non-recursive queries to the listed servers
and will honor delegations. I've tested this configuration in our lab
and it all appears to be working.

With our configuration, are there any downsides to changing from forward
zones to static-stub? Any gotchas I should know about? At this time we
don't have dnssec validation turned on. We tried it and had too many
problems with misconfigured domains not resolving properly so backed out.



Oscar

[Chris Buxton]

On Sep 20, 2012, at 5:49 PM, Oscar Ricardo Silva wrote:

> I have several recursive, caching BIND servers

[...]

> The current servers are configured to forward any queries for our domain straight to our authoritative servers

[...]

> I've been reading about the new zone type: static-stub and believe this may work better for us.

[...]

> If I'm correct, it will send non-recursive queries to the listed servers and will honor delegations. I've tested this configuration in our lab and it all appears to be working.
>
> With our configuration, are there any downsides to changing from forward zones to static-stub?

Type static-stub should work great here. Type stub, which has been around since before I started managing DNS servers (a very long time now), would probably also have worked.

Chris Buxton
BlueCat Networks

[Tony Xue]

Hello,

Ehhh, what's a static-stub type? Why I never read this in the file?
-----Original Message-----
From: Chris Buxton <chris.p...@gmail.com>
Sender: bind-users-bounces+xuezxbb=gmai...@lists.isc.orgDate: Thu, 20 Sep 2012 19:35:23
To: Oscar Ricardo Silva<osi...@scuff.cc.utexas.edu>
Cc: <bind-...@lists.isc.org>
Subject: Re: Moving from "type forward" to "type static-stub"

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-...@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Adam Tkac]

On Thu, Sep 20, 2012 at 07:49:08PM -0500, Oscar Ricardo Silva wrote:
> I have several recursive, caching BIND servers that were running the
> Redhat package of BIND. Our servers started crashing because of a
> bug (previously identified AND fixed by ISC) so we've decided to
> ditch that version and run from source, 9.9.1-P3. (I'm still not
> sure why redhat decided to use the rc1 version of source on which to
> build their rpm ... seriously ... the bug that hit us was fixed in
> rc2 AND the final release)

Because rc2 was released too late to get it into RHEL 6.3... Btw which is the
bug that bothers you? Why don't you report it to RH bugzilla?

Regards, Adam

--
Adam Tkac, Red Hat, Inc.

[Niall O'Reilly]

On 21 Sep 2012, at 08:55, Adam Tkac wrote:

> Because rc2 was released too late to get it into RHEL 6.3... Btw which is the
> bug that bothers you? Why don't you report it to RH bugzilla?

I don't understand why RH would choose to include a release candidate
rather than a stable release.

/Niall

[Adam Tkac]

ISC's RCs are generally OK. When I updated BIND in 6.3, I could choose either
9.8.1-P* or 9.8.2rc1. So I decided to pick 9.8.2rc1 because it contains many
bugfixes over 9.8.1. And from 9.8.2 changelog it doesn't seems there are
regression fixes for bugs which aren't present in 9.8.1, are present in 9.8.2rc1
and are fixed in 9.8.2 (except RT #27738 which is already fixed).

However it seems you hit some bug which isn't present in 9.8.1, is present in
9.8.2rc1 and is fixed in 9.8.2. Can you please tell me number of that bug so we
can backport the patch? Thank you in advance.

[Oscar Ricardo Silva]

On 09/21/2012 02:55 AM, Adam Tkac wrote:
> On Thu, Sep 20, 2012 at 07:49:08PM -0500, Oscar Ricardo Silva wrote:
>> I have several recursive, caching BIND servers that were running the
>> Redhat package of BIND. Our servers started crashing because of a
>> bug (previously identified AND fixed by ISC) so we've decided to
>> ditch that version and run from source, 9.9.1-P3. (I'm still not
>> sure why redhat decided to use the rc1 version of source on which to
>> build their rpm ... seriously ... the bug that hit us was fixed in
>> rc2 AND the final release)
>

> Because rc2 was released too late to get it into RHEL 6.3... Btw which is the
> bug that bothers you? Why don't you report it to RH bugzilla?
>

> Regards, Adam


Case opened with Redhat: 2012-07-02
Bug: 837165 (opened on 2012-07-02)
Proposed patch (by Adam): 2012-07-09
Patch released: 2012-07-23 (but not noted in Bugzilla)
Notification of bug fix: 2012-07-31
(per Bugzilla)
Number of crashes after
bug reported: 3 (2 initial crashes, 3 more after)

We did report it and a patch was released AFTER our servers started
crashing on the known bug. Even then, when one server had crashed twice
and we were holding our breath on the others, it took weeks for the
patched version to come through.

I don't want to get in a war of words but here's the first line from the
9.8.2rc1 Release Notes:

*************************
BIND 9.8.2rc1 is the first release candidate of BIND 9.8.2.
*************************

Not only is it a release candidate but it's the FIRST release candidate.
Also, using the dates on the release notes:

2012-01-19 9.8.2rc1
2012-03-13 9.8.2rc1
2012-03-23 9.8.2rc1
...
2012-06-21 RHEL 6.3 announced as available

I wonder if there's no process to revisit a package after a final
version has been released. I'm aware that you have to pick something
but if it's not a final version why not go back after the official
version is available.

Sorry for going way off topic (package version vs an actual BIND
problem) but the question was asked. Personally it drives me nuts when
people just complain on a mailing list but then don't report it through
official channels so I wanted to show that we did do that.


Oscar

[Oscar Ricardo Silva]

On 09/20/2012 09:35 PM, Chris Buxton wrote:

> On Sep 20, 2012, at 5:49 PM, Oscar Ricardo Silva wrote:
>
>> I have several recursive, caching BIND servers
>

> [...]
>
>> The current servers are configured to forward any queries for our domain straight to our authoritative servers
>
> [...]
>
>> I've been reading about the new zone type: static-stub and believe this may work better for us.
>
> [...]
>
>> If I'm correct, it will send non-recursive queries to the listed servers and will honor delegations. I've tested this configuration in our lab and it all appears to be working.
>>
>> With our configuration, are there any downsides to changing from forward zones to static-stub?
>
> Type static-stub should work great here. Type stub, which has been around since before I started managing DNS servers (a very long time now), would probably also have worked.
>
> Chris Buxton
> BlueCat Networks

I've been asked why I don't just make these slave zones. It seems like
a good idea and would reduce the amount of traffic to the authoritative
servers.

Any negatives in converting to slave zones from "forward" or
"static-stub"? The authoritative servers send a NOTIFY when records
have changed so the caching servers would refresh their zones.

[Michael Sinatra]

On 9/20/12 5:49 PM, Oscar Ricardo Silva wrote:

> If I'm correct, it will send non-recursive queries to the listed servers
> and will honor delegations. I've tested this configuration in our lab
> and it all appears to be working.

Yup, static stub will do exactly that.

> With our configuration, are there any downsides to changing from forward

> zones to static-stub? Any gotchas I should know about?

I am pretty sure that the recursive server will still cache the entries
it receives from the static-stub server. If your goal is for
"instantaneous" updates on your recursives when your authoritatives get
update, I don't think it will work as well as just slaving the zones.

If the goal is for the recursives to see an internal view of the zones,
then static-stub will work great.

> At this time we
> don't have dnssec validation turned on. We tried it and had too many
> problems with misconfigured domains not resolving properly so backed out.

It's time to back in again (front in?). Now that Comcast is validating,
any mistakes that people make will get fixed right quick. 1.7 million
people doing validation is good incentive to get things right and fix
them quickly. At UC Berkeley, validation has been turned on for four
years now and only a handful of domains have required "special handling."

All of the emphasis on signing for DNSSEC is great, but DNSSEC can't
really work without validation.

michael

[Phil Mayers]

>
>It's time to back in again (front in?). Now that Comcast is
>validating,
>any mistakes that people make will get fixed right quick. 1.7 million
>people doing validation is good incentive to get things right and fix
>them quickly. At UC Berkeley, validation has been turned on for four
>years now and only a handful of domains have required "special
>handling."
>
>All of the emphasis on signing for DNSSEC is great, but DNSSEC can't
>really work without validation.
>

+a lot
--
Sent from my phone. Please excuse brevity and typos.

[Matus UHLAR - fantomas]

On 20.09.12 19:49, Oscar Ricardo Silva wrote:
>The current servers are configured to forward any queries for our

>domain straight to our authoritative servers:

>
>I've been reading about the new zone type: static-stub and believe
>this may work better for us.
>

>If I'm correct, it will send non-recursive queries to the listed
>servers and will honor delegations. I've tested this configuration in
>our lab and it all appears to be working.
>

>With our configuration, are there any downsides to changing from

>forward zones to static-stub? Any gotchas I should know about? At

>this time we don't have dnssec validation turned on. We tried it and
>had too many problems with misconfigured domains not resolving
>properly so backed out.

typo forward supports "forward first" which is good if you have e.g. local
versions of blacklists but want to use standard resolution when your local
servers are unreachable.

--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759