Re: named start-up behavior

[Gordon A. Lang]

Okay, so my named process rejecting my slave files during start up does
not represent a new feature of the newer code -- that's a relief.

Now, considering the observed behavior to be improper, I see my expiry
was too short.  Since my files were older than my expiry, I guess that
explains it.

But that leaves two questions:

 - Why didn't my log files include a message indicating the zones were
   being rejected due to expiration?

 - Does anyone know where the start up behavior is documented online?


Thanks.

--
Gordon A. Lang

- Original Message - 
From: "Barry Margolin" 

Newsgroups: comp.protocols.dns.bind
To: 
Sent: Thursday, August 26, 2010 9:31 PM
Subject: Re: named start-up behavior



In article ,
"Gordon A. Lang"  wrote:


I have not been able to locate documentation defining the named
start-up behavior.  I am particularly interested in zone loading
for slave zones.  Is this information available online?

For example, what if none of the listed masters are reachable at
the time of start-up?  How frequently and for how long is it
retried?  Can this be tweaked?  Can the data on disk (if present)
be used as an interim better than nothing source?


The SOA Retry, and Expire timers control how frequently BIND will retry 
failing zone transfers and how long they be retried.




If my memory isn't failing me, I thought the old BIND code used
disk data for slaves before zone transfers -- can anyone confirm
or refute this?  Can anyone explain why a slave should never load
from disk (in the event of a zone transfer failure)?


That's exactly what happens.  What do you think the file is for, if not 
to load it at startup?


BIND uses the file's timestamp to schedule the refresh timer.  So if the 
SOA Refresh time is 6 hours, and the file is 1 hour old when BIND starts 
up, it will schedule a zone transfer for 5 hours later.


--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


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

Re: named start-up behavior

[Barry Margolin]

In article ,
 "Gordon A. Lang"  wrote:

> I have not been able to locate documentation defining the named
> start-up behavior.  I am particularly interested in zone loading
> for slave zones.  Is this information available online?
> 
> For example, what if none of the listed masters are reachable at
> the time of start-up?  How frequently and for how long is it
> retried?  Can this be tweaked?  Can the data on disk (if present)
> be used as an interim better than nothing source?

The SOA Retry, and Expire timers control how frequently BIND will retry 
failing zone transfers and how long they be retried.

> 
> If my memory isn't failing me, I thought the old BIND code used
> disk data for slaves before zone transfers -- can anyone confirm
> or refute this?  Can anyone explain why a slave should never load
> from disk (in the event of a zone transfer failure)?

That's exactly what happens.  What do you think the file is for, if not 
to load it at startup?

BIND uses the file's timestamp to schedule the refresh timer.  So if the 
SOA Refresh time is 6 hours, and the file is 1 hour old when BIND starts 
up, it will schedule a zone transfer for 5 hours later.

-- 
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zero SOA TTL - still best practice?

[Mark Andrews]

You may also want to look at draft-andrews-dnsext-soa-discovery-01.txt.
Updatable zones have different needs to relatively stable zones.

Mobile (all?) machines should be able to add PTR records for
themselves when they aquire the leases or complete SLAAC and that
requires zone cut discovery.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

BIND 9.7.2rc1 is now available.

[Mark Andrews]

BIND 9.7.2rc1 is now available.

BIND 9.7.2rc1 is a beta version of the maintenance release for
BIND 9.7.

BIND 9.7.2rc1 can be downloaded from

ftp://ftp.isc.org/isc/bind9/9.7.2rc1/bind-9.7.2rc1.tar.gz
http://ftp.isc.org/isc/bind9/9.7.2rc1/bind-9.7.2rc1.tar.gz

The PGP signature of the distribution is at

ftp://ftp.isc.org/isc/bind9/9.7.2rc1/bind-9.7.2rc1.tar.gz.asc
ftp://ftp.isc.org/isc/bind9/9.7.2rc1/bind-9.7.2rc1.tar.gz.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.7.2rc1/bind-9.7.2rc1.tar.gz.sha512.asc

http://ftp.isc.org/isc/bind9/9.7.2rc1/bind-9.7.2rc1.tar.gz.asc
http://ftp.isc.org/isc/bind9/9.7.2rc1/bind-9.7.2rc1.tar.gz.sha256.asc
http://ftp.isc.org/isc/bind9/9.7.2rc1/bind-9.7.2rc1.tar.gz.sha512.asc

The signature was generated with the ISC public key, which is
available at .

A binary kit for Windows XP and Window 2003 is at

ftp://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.zip
http://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.zip

ftp://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.debug.zip
http://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.debug.zip

The PGP signature of the binary kit for Windows XP and Window 2003 is at

ftp://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.zip.asc
ftp://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.zip.sha512.asc

http://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.zip.asc
http://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.zip.sha256.asc
http://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.zip.sha512.asc

ftp://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.debug.zip.asc
ftp://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.debug.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.debug.zip.sha512.asc

http://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.debug.zip.asc
http://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.debug.zip.sha256.asc
http://ftp.isc.org/isc/bind9/9.7.2rc1/BIND9.7.2rc1.debug.zip.sha512.asc

Changes since 9.7.0.

--- 9.7.2rc1 released ---

2943.   [func]  Add support to load new keys into managed zones
without signing immediately with "rndc loadkeys".
Add support to link keys with "dnssec-keygen -S"
and "dnssec-settime -S".  [RT #21351]

2942.   [contrib]   zone2sqlite failed to setup the entropy sources.
[RT #21610]

2941.   [bug]   sdb and sdlz (dlz's zone database) failed to support
DNAME at the zone apex.  [RT #21610]

2940.   [port]  Remove connection aborted error message on
Windows. [RT #21549]

2939.   [func]  Check that named successfully skips NSEC3 records
that fail to match the NSEC3PARAM record currently
in use. [RT# 21868]

2938.   [bug]   When generating signed responses, from a signed zone
that uses NSEC3, named would use a uninitialised
pointer if it needed to skip a NSEC3 record because
it didn't match the selected NSEC3PARAM record for
zone. [RT# 21868]

2937.   [bug]   Worked around an apparent race condition in over
memory conditions.  Without this fix a DNS cache DB or
ADB could incorrectly stay in an over memory state,
effectively refusing further caching, which
subsequently made a BIND 9 caching server unworkable.
This fix prevents this problem from happening by
polling the state of the memory context, rather than
making a copy of the state, which appeared to cause
a race.  This is a "workaround" in that it doesn't
solve the possible race per se, but several experiments
proved this change solves the symptom.  Also, the
polling overhead hasn't been reported to be an issue.
This bug should only affect a caching server that
specifies a finite max-cache-size.  It's also quite
likely that the bug happens only when enabling threads,
but it's not confirmed yet. [RT #21818]

2936.   [func]  Improved configuration syntax and multiple-view
support for addzone/delzone feature (see change
#2930).  Removed "new-zone-file" option, replaced
with "allow-new-zones (yes|no)".  The new-zone-file
for each view is now creat

Re: zero SOA TTL - still best practice?

[Karl Auer]

On Thu, 2010-08-26 at 11:23 -0400, Josh Littlefield wrote:
> Confirming, RFC 2308 makes it clear that the negative caching of all
> records for a zone is limited to the minimum of the SOA TTL and the SOA
> "minimum" TTL field (which was given this new negative caching TTL role
> in RFC 2308).

It's not clear to me why the lesser of the two is taken, or indeed why
they have a relationship at all. What is the rationale there? Why not
just use the minimum TTL as the negative cache TTL?

Having read the history in RFC2308, I suspect it is because the minimum
TTL has had a few meanings over time, and was often set far too high, so
the SOA TTL is being used to "sanity check" it, as even a feral zone
administrator will not want too high a value in the SOA TTL.

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


signature.asc
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

rndc reconfig delays

[Rob Foehl]

I've been experimenting with loading a large number of master zones (on 
the order of 250,000) in a single BIND instance, and have noticed that 
'rndc reconfig' with this many zones loaded can take a very long time to 
determine that it has little or nothing to do.  Worse, the server stops 
answering other requests for the duration, in both threaded and 
non-threaded builds -- I'm testing with 64 bit builds of both 9.7.0-P1 and 
9.7.1-P2.


In the best case, a reconfig will take about 40 seconds to complete, and 
stalls the server for most of that time.  Loading zones in bulk is 
substantially slower, but is less of an issue for the intended use, and is 
more or less limited by the speed of the storage.


My next step is going to be to experiment with the rndc addzone/delzone 
feature in the 9.7.2 betas, which hopefully should avoid any need to 
attempt a reconfig during normal use.  That aside, is there anything else 
I could be doing to speed things up?


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

Re: zero SOA TTL - still best practice?

[Karl Auer]

On Thu, 2010-08-26 at 23:17 +1000, Karl Auer wrote:
> - should I update my program to allow non-zero SOA TTLs?

The answer appears to be "yes, right now!" :-)

RFC2308.

Many thanks for your swift responses (and Alex, how could I ever have
doubted you?)

Regards, K.

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


signature.asc
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zero SOA TTL - still best practice?

[Chris Thompson]

On Aug 26 2010, Kevin Oberman wrote:

[...]

The SOA record should have a reasonable TTL, and the "minimum" field in
the SOA should also be set to a reasonable value, no larger than the SOA
TTL.  If you don't change your zone data often, then you should let
people cache your negative answers for a useful amount of time (hours,
days).


I really question the desirability of a negative cache TTL of days. If
something is not in DNS when it is first queried for, it will be
negatively cached and will stay that way for a very long time. It is not
unheard of for some information on a new web page to be leaked (at least
internally) prior to the insertion of the record into DNS. An
excessively long negative cache time will keep it unavailable for fat
too long.


Yes, one needs to take into account whether the zone will remain
static, and whether one will have advance notice of a change. But
there are zones whose contents truly do not change for years on
end, and I have no hesitation in using an SOA.minimum value of
24 hours for them. Even though ...


I remember discussions in the DNSEXT WG back when negative caching was
fist implemented as to whether the negative cache time should be limited
and, if so, to how many MINUTES.


Hence BIND's default max-ncache-ttl of 3 hours.

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zero SOA TTL - still best practice?

[Kevin Oberman]

It makes the tread hard to follow
> Why not?
> > Please don't top post!

> On 8/26/2010 10:52 AM, Alexander Gall wrote:
> > Hello Karl
> >
> > On Thu, 26 Aug 2010 23:17:29 +1000, Karl Auer  said:
> >
> >> Some time ago (at least six years) I wrote a program that, among many
> >> other related operations, creates new zones for a nameserver. This
> >> program creates new zones that have a TTL value of zero for the SOA
> >> record.
> >> That's what RFC1035 seems to say it should do. When describing TTLs, it
> >> says "For example, SOA records are always distributed with a zero TTL to
> >> prohibit caching."
> > RFC 2181 section 7.2 clarifies that this advice should be ignored.
> >
> >> That isn't very prescriptive, now that I think about it. It doesn't say
> >> that it should or must happen - just that it happens. But it does make
> >> sense to me, now as then - why would anyone want to cache an SOA?
> >> There's a sort-of-related BIND config item, "zero-no-soa-ttl", the
> >> description of which states:
> >>"When returning authoritative negative responses to SOA queries set
> >> the TTL of the SOA record returned in the authority section to
> >> zero. The default is yes."
> >> That's only for negative responses, and only for SOA queries. Still, it
> >> does seem to suggest that other people think there's generally no need
> >> to cache SOA records, and especially not negatively.
> >> Anyway, I just received an email from someone who runs a secondary for
> >> us saying that he was getting a constant 50 qps for a non-existent RR.
> >> He says that if our SOA had a non-zero TTL, it would get cached and the
> >> problem would move downstream and that would be nice. He *also* says
> >> that the SOA TTL acts as an upper bound for the negative caching TTL.
> > [I'm that guy :]
> >
> >> I don't think he is right on either count. The querying nameserver gets
> >> an SOA record returned, and in that record is the negative caching TTL
> >> it should use. That is, it may not cache the SOA, but it isn't *looking*
> >> for the SOA. It's getting one as a side effect of looking up something
> >> that doesn't exist. The TTL of the SOA is not having any effect here.
> > RFC 2308, section 3
> >
> >The TTL of this [SOA record in authority section of negative response]
> >record is set from the minimum of the MINIMUM field of the SOA record
> >and the TTL of the SOA itself, and indicates how long a resolver may
> >cache the negative answer. 
> >
> >> That said, a non-zero SOA TTL certainly seems to be common, perhaps the
> >> norm.
> > I don't think so.  This was an issue for the org zone as well (with
> > further implications for DNSKEY records), see
> > 
> >> So to my questions:
> >> - have I got totally and completely the wrong end of the stick here?
> > My reading of the specs would suggest that.
> >
> >> - should I update my program to allow non-zero SOA TTLs?
> > 
> > Yes, unless I'm the one with the wrong end of the stick :)
> >
> Date: Thu, 26 Aug 2010 11:23:00 -0400
> From: Josh Littlefield 
> Sender: bind-users-bounces+oberman=es@lists.isc.org
> 
>  Confirming, RFC 2308 makes it clear that the negative caching of all
> records for a zone is limited to the minimum of the SOA TTL and the SOA
> "minimum" TTL field (which was given this new negative caching TTL role
> in RFC 2308).  If you put a 0 TTL on your SOA records, no one can cache
> your negative answers, which can cause you and them a bit of pain.
> 
> The SOA record should have a reasonable TTL, and the "minimum" field in
> the SOA should also be set to a reasonable value, no larger than the SOA
> TTL.  If you don't change your zone data often, then you should let
> people cache your negative answers for a useful amount of time (hours,
> days).

I really question the desirability of a negative cache TTL of days. If
something is not in DNS when it is first queried for, it will be
negatively cached and will stay that way for a very long time. It is not
unheard of for some information on a new web page to be leaked (at least
internally) prior to the insertion of the record into DNS. An
excessively long negative cache time will keep it unavailable for fat
too long.

I remember discussions in the DNSEXT WG back when negative caching was
fist implemented as to whether the negative cache time should be limited
and, if so, to how many MINUTES.

The purpose of the negative cache is to keep servers from being
continually beaten on and reducing queries from some broken piece of
software from hundreds of queries/second to 4 or 5 per minute. (And
there were and probably are things still making hundreds of
queries/second because some resolvers are badly broken.) Making it
hours or days long will do little to off-load the root, ccTLD, gTLD, or
any other servers while increasing the opportunity to shoot oneself in
the foot. This has little or no link to how oft

named start-up behavior

[Gordon A. Lang]

I have not been able to locate documentation defining the named
start-up behavior.  I am particularly interested in zone loading
for slave zones.  Is this information available online?

For example, what if none of the listed masters are reachable at
the time of start-up?  How frequently and for how long is it
retried?  Can this be tweaked?  Can the data on disk (if present)
be used as an interim better than nothing source?

If my memory isn't failing me, I thought the old BIND code used
disk data for slaves before zone transfers -- can anyone confirm
or refute this?  Can anyone explain why a slave should never load
from disk (in the event of a zone transfer failure)?

Thanks.

--
Gordon A. Lang
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zero SOA TTL - still best practice?

[Josh Littlefield]

 Confirming, RFC 2308 makes it clear that the negative caching of all
records for a zone is limited to the minimum of the SOA TTL and the SOA
"minimum" TTL field (which was given this new negative caching TTL role
in RFC 2308).  If you put a 0 TTL on your SOA records, no one can cache
your negative answers, which can cause you and them a bit of pain.

The SOA record should have a reasonable TTL, and the "minimum" field in
the SOA should also be set to a reasonable value, no larger than the SOA
TTL.  If you don't change your zone data often, then you should let
people cache your negative answers for a useful amount of time (hours,
days).

-josh

On 8/26/2010 10:52 AM, Alexander Gall wrote:
> Hello Karl
>
> On Thu, 26 Aug 2010 23:17:29 +1000, Karl Auer  said:
>
>> Some time ago (at least six years) I wrote a program that, among many
>> other related operations, creates new zones for a nameserver. This
>> program creates new zones that have a TTL value of zero for the SOA
>> record.
>> That's what RFC1035 seems to say it should do. When describing TTLs, it
>> says "For example, SOA records are always distributed with a zero TTL to
>> prohibit caching."
> RFC 2181 section 7.2 clarifies that this advice should be ignored.
>
>> That isn't very prescriptive, now that I think about it. It doesn't say
>> that it should or must happen - just that it happens. But it does make
>> sense to me, now as then - why would anyone want to cache an SOA?
>> There's a sort-of-related BIND config item, "zero-no-soa-ttl", the
>> description of which states:
>>"When returning authoritative negative responses to SOA queries set
>> the TTL of the SOA record returned in the authority section to
>> zero. The default is yes."
>> That's only for negative responses, and only for SOA queries. Still, it
>> does seem to suggest that other people think there's generally no need
>> to cache SOA records, and especially not negatively.
>> Anyway, I just received an email from someone who runs a secondary for
>> us saying that he was getting a constant 50 qps for a non-existent RR.
>> He says that if our SOA had a non-zero TTL, it would get cached and the
>> problem would move downstream and that would be nice. He *also* says
>> that the SOA TTL acts as an upper bound for the negative caching TTL.
> [I'm that guy :]
>
>> I don't think he is right on either count. The querying nameserver gets
>> an SOA record returned, and in that record is the negative caching TTL
>> it should use. That is, it may not cache the SOA, but it isn't *looking*
>> for the SOA. It's getting one as a side effect of looking up something
>> that doesn't exist. The TTL of the SOA is not having any effect here.
> RFC 2308, section 3
>
>The TTL of this [SOA record in authority section of negative response]
>record is set from the minimum of the MINIMUM field of the SOA record
>and the TTL of the SOA itself, and indicates how long a resolver may
>cache the negative answer. 
>
>> That said, a non-zero SOA TTL certainly seems to be common, perhaps the
>> norm.
> I don't think so.  This was an issue for the org zone as well (with
> further implications for DNSKEY records), see
> 
>> So to my questions:
>> - have I got totally and completely the wrong end of the stick here?
> My reading of the specs would suggest that.
>
>> - should I update my program to allow non-zero SOA TTLs?
> 
> Yes, unless I'm the one with the wrong end of the stick :)
>

-- 
Josh Littlefield  Cisco Systems, Inc.
jo...@cisco.com 1414 Massachusetts Avenue
Phone: +1 978-936-0001 Boxborough, MA  01719-2205

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

Re: zero SOA TTL - still best practice?

[Alan Clegg]

On 8/26/2010 10:52 AM, Alexander Gall wrote:

>> - should I update my program to allow non-zero SOA TTLs?
> 
> Yes, unless I'm the one with the wrong end of the stick :)

Zero TTLs are evil.

Please don't use them (and if possible, update the zones that you have
deployed with zero TTLs to use something more sane).

AlanC




signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zero SOA TTL - still best practice?

[Alexander Gall]

Hello Karl

On Thu, 26 Aug 2010 23:17:29 +1000, Karl Auer  said:

> Some time ago (at least six years) I wrote a program that, among many
> other related operations, creates new zones for a nameserver. This
> program creates new zones that have a TTL value of zero for the SOA
> record.

> That's what RFC1035 seems to say it should do. When describing TTLs, it
> says "For example, SOA records are always distributed with a zero TTL to
> prohibit caching."

RFC 2181 section 7.2 clarifies that this advice should be ignored.

> That isn't very prescriptive, now that I think about it. It doesn't say
> that it should or must happen - just that it happens. But it does make
> sense to me, now as then - why would anyone want to cache an SOA?

> There's a sort-of-related BIND config item, "zero-no-soa-ttl", the
> description of which states:

>"When returning authoritative negative responses to SOA queries set
> the TTL of the SOA record returned in the authority section to
> zero. The default is yes."

> That's only for negative responses, and only for SOA queries. Still, it
> does seem to suggest that other people think there's generally no need
> to cache SOA records, and especially not negatively.

> Anyway, I just received an email from someone who runs a secondary for
> us saying that he was getting a constant 50 qps for a non-existent RR.
> He says that if our SOA had a non-zero TTL, it would get cached and the
> problem would move downstream and that would be nice. He *also* says
> that the SOA TTL acts as an upper bound for the negative caching TTL.

[I'm that guy :]

> I don't think he is right on either count. The querying nameserver gets
> an SOA record returned, and in that record is the negative caching TTL
> it should use. That is, it may not cache the SOA, but it isn't *looking*
> for the SOA. It's getting one as a side effect of looking up something
> that doesn't exist. The TTL of the SOA is not having any effect here.

RFC 2308, section 3

   The TTL of this [SOA record in authority section of negative response]
   record is set from the minimum of the MINIMUM field of the SOA record
   and the TTL of the SOA itself, and indicates how long a resolver may
   cache the negative answer. 

> That said, a non-zero SOA TTL certainly seems to be common, perhaps the
> norm.

I don't think so.  This was an issue for the org zone as well (with
further implications for DNSKEY records), see

> So to my questions:

> - have I got totally and completely the wrong end of the stick here?

My reading of the specs would suggest that.

> - should I update my program to allow non-zero SOA TTLs?

Yes, unless I'm the one with the wrong end of the stick :)

-- 
Alex

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

zero SOA TTL - still best practice?

[Karl Auer]

Some time ago (at least six years) I wrote a program that, among many
other related operations, creates new zones for a nameserver. This
program creates new zones that have a TTL value of zero for the SOA
record.

That's what RFC1035 seems to say it should do. When describing TTLs, it
says "For example, SOA records are always distributed with a zero TTL to
prohibit caching."

That isn't very prescriptive, now that I think about it. It doesn't say
that it should or must happen - just that it happens. But it does make
sense to me, now as then - why would anyone want to cache an SOA?

There's a sort-of-related BIND config item, "zero-no-soa-ttl", the
description of which states:

   "When returning authoritative negative responses to SOA queries set
the TTL of the SOA record returned in the authority section to
zero. The default is yes."

That's only for negative responses, and only for SOA queries. Still, it
does seem to suggest that other people think there's generally no need
to cache SOA records, and especially not negatively.

Anyway, I just received an email from someone who runs a secondary for
us saying that he was getting a constant 50 qps for a non-existent RR.
He says that if our SOA had a non-zero TTL, it would get cached and the
problem would move downstream and that would be nice. He *also* says
that the SOA TTL acts as an upper bound for the negative caching TTL.

I don't think he is right on either count. The querying nameserver gets
an SOA record returned, and in that record is the negative caching TTL
it should use. That is, it may not cache the SOA, but it isn't *looking*
for the SOA. It's getting one as a side effect of looking up something
that doesn't exist. The TTL of the SOA is not having any effect here.

That said, a non-zero SOA TTL certainly seems to be common, perhaps the
norm.

So to my questions:

- have I got totally and completely the wrong end of the stick here?

- should I update my program to allow non-zero SOA TTLs?

Regards, K.

PS: The specific query is for "swisstime.ee.ethz.ch ".

-- 
~~~
Karl Auer (ka...@biplane.com.au)   +61-2-64957160 (h)
http://www.biplane.com.au/kauer/   +61-428-957160 (mob)

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF


signature.asc
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Trouble with 9.7.1-P2 on RHEL 5

[CT]

I have successfully built on CentOS 5.5 (32bit)
(I do a very simple install with no desktop.. )

BIND 9.7.1-P2 built with '--prefix=/usr/local' 
'--sysconfdir=/etc/namedb' '--disable-openssl-version-check' 
'--with-openssl=yes'


Some notes I had made
---
Compiling from source is very simple once you have the necessary 
dependancies.


Needed to compile bind from source:
-- openssl
-- make
are installed during the default installation

We need to install a few extra packages via yum.
These package will also pull in a few of their own dependancies.

-- yum install openssl-devel
-- yum install gcc
-- yum install autoconf

---
hth
Charles


Timothy Holtzen wrote:

Has anyone been able to get 9.7.1-P2 to build with pkcs11 and run on
RHEL/CentOS 5?  I appear to be able to configure and make without any
problems but when I go to run it I get the following error in the log.

named[14899]: starting BIND 9.7.1-P2 -c /etc/named.conf -t /var/named/chroot
named[14899]: built with '--with-libtool' '--localstatedir=/var'
'--disable-threads' '--enable-ipv6' '--disable-static' '--with-pic'
'--disable-openssl-version-check'
'--with-pkcs11=/usr/lib64/pkcs11/PKCS11_API.so' '--with-gssapi=yes'
'--disable-isc-spnego'
named[14899]: using up to 4096 sockets
named[14899]: initializing DST: no engine
named[14899]: exiting (due to fatal error)

> From what I have been able to deduce this means that bind can't find or
use the pkcs11 encryption engine.  Compiling without the "--with-pkcs11"
option produces a functional executable.  Stangely the exact same
configuration options worked just fine with 9.7.0 so something seems to
have changed between those releases.  My ultimate goal is to do a full
DNSSEC depolyment so I'm guessing the pkcs11 option is going to be
required if I want to generate and manage keys etc.  Anyone have any
ideas?  I suspect that I'm missing some encription library or something.




-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFMdZX2DADXcoYj2ZwRAuggAJ49JS5iERRDzRuzZu7D9B3c8Ui7bQCcCb0R
deKtj3MANUTquQilmCJ7Dsw=
=tHat
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


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