Re: rndc reconfig delays

[Larissa Shapiro]

Probably. I'd like to get Michael's feedback... I have not heard of  
this from anyone else have either of you?


On Aug 26, 2010, at 3:22 PM, Rob Foehl wrote:

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



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

Re: caching of "server fail" BIND9

[Matus UHLAR - fantomas]

Hello,

please configure your mailer to wrap lines below 80 characters per line.
72 to 75 is usually OK.

Thank you.

On 24.08.10 09:49, Len Conrad wrote:
> We just had a problem where a BIND9 running on our postfix MX
> 451-rejected-as-unknown-domain all msgs from @sender.domain for 9 days.
> 
> "rndc flush" allowed the domain to be resolved immediately and its
> messages accepted.
> 
> When the BIND reports "server fail", rather than a negative answer with
> neg-TTL, how long is SRV FAIL cached in BIND9?  RFC2308 says "no longer
> than 5 minutes".

this applies for "server failure" and "dead/unreachable" responses, not for
responses as "name error" or "no data". 

> We do not know whether unknown domain's NS was really SRV FAIL for 9 days.

each zone defined the negative TTL, stored in SOA "minimum" field (which has
now only this usage therefore it should be renamed).

check the SOA of "sender.domain" to see how big the TTL is.

-- 
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.
Spam is for losers who can't get business any other way.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: discrepancy with rndc dumpdb -zones

[Matus UHLAR - fantomas]

On 24.08.10 16:56, Gordon A. Lang wrote:
> After several successful "update delete ..." nsupdate sends to the master
> DNS server, verified with dig, the "rndc dumpdb -zones" command produced
> named_dump.db file still showing the deleted records.  This was repeatable
> and persistent (over the half hour time period) until I performed a hard
> restart of named.

maybe journal for IXFR queries?

-- 
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.
Fucking windows! Bring Bill Gates! (Southpark the movie)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zero SOA TTL - still best practice?

[Matus UHLAR - fantomas]

> On Thu, 26 Aug 2010 23:17:29 +1000, Karl Auer  said:
> > That said, a non-zero SOA TTL certainly seems to be common, perhaps the
> > norm.

On 26.08.10 16:52, Alexander Gall wrote:
> I don't think so.  This was an issue for the org zone as well (with
> further implications for DNSKEY records), see
> 

well, the issue was with zero TTL coming from SOA, so the non-zero really is
common, a norm, or do I misunderstand you?
-- 
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.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: dnssec questions

[Alan Clegg]

On 8/27/2010 11:42 AM, CT wrote:

> Per my isc class and the book I received by Jeremy C. Reid ..
> you still need to "include" your keys in the zone file either
> 
> via
> $include /KSK
> $include /ZSK1
> $include /ZSK2
> or
> (cat *.key > allkeys) which is what I have done..
> $include /allkeys
> 
> I thought the use of -S (smart signing) that this was no longer
> necessary ..?

If you use "-S", dnssec-signzone pulls the keys into the zone file based
on the timing metadata.  You don't need to $INCLUDE the keys any longer.

AlanC



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

dnssec questions

[CT]

I just migrated my dns server to bind 9.7.1-P2

KSK
dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -f KSK $zone

ZSK
dnssec-keygen -r /dev/urandom -a RSASHA256 -b 1024 $zone

SIGN
dnssec-signzone -S -C -g -a -H 10 -3  -K  $zone

Per my isc class and the book I received by Jeremy C. Reid ..
you still need to "include" your keys in the zone file either

via
$include /KSK
$include /ZSK1
$include /ZSK2
or
(cat *.key > allkeys) which is what I have done..
$include /allkeys

I thought the use of -S (smart signing) that this was no longer 
necessary ..?


Thx
Charles



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

Re: dnssec questions

[CT]

On 08/27/2010 11:32 AM, Alan Clegg wrote:

On 8/27/2010 11:42 AM, CT wrote:


Per my isc class and the book I received by Jeremy C. Reid ..
you still need to "include" your keys in the zone file either

via
$include/KSK
$include/ZSK1
$include/ZSK2
or
(cat *.key>  allkeys) which is what I have done..
$include/allkeys

I thought the use of -S (smart signing) that this was no longer
necessary ..?





If you use "-S", dnssec-signzone pulls the keys into the zone file based
on the timing metadata.  You don't need to $INCLUDE the keys any longer.

AlanC



Alan..

Much thanks for the info.. I had to include the keys for my keyset 
upload to our registrar.. and it did require the keys either in the file

or with an include statement.. so a one time deal then..

Also discovered (was using 9.6.1-16.P3 before) the keyset does not 
change after re-signing the zone...


One less file to keep up with ..

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

rndc addzone/delzone in 9.7.2rc1 (was: rndc reconfig delays)

[Rob Foehl]

On Thu, 26 Aug 2010, Rob Foehl wrote:

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?


I suppose it's fortuitous that 9.7.2rc1 was released so shortly after I'd 
written the above; what may have been an ideal solution is no longer so 
with this change:


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 created automatically, with
a filename generated from a hash of the view name.
It is no longer necessary to "include" the
new-zone-file in named.conf; this happens
automatically.  Zones that were not added via
"rndc addzone" can no longer be removed with
"rndc delzone". [RT #19447]

I'm having a hard time following the motivation behind these changes.  Why 
is the filename non-configurable and non-obvious?  Why take away the 
ability to remove arbitrary zones from the current configuration?  This 
change makes this feature irrelevant when dealing with zone counts in the 
six figure range, as my interest here was in the ability to maintain the 
configuration and the server state in parallel without a reconfig.


I have not yet done any testing of the responsiveness of addzone/delzone 
vs. reconfig with a full set of zones loaded, so this may be entirely 
irrelevant anyway, but I'd love to get a better idea of the future 
direction of this feature before I go any further down this path.


Thanks,

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

Re: rndc addzone/delzone in 9.7.2rc1 (was: rndc reconfig delays)

[Evan Hunt]

> I'm having a hard time following the motivation behind these changes.  Why 
> is the filename non-configurable and non-obvious?

"Non-configurable" may change.

"Non-obvious" isn't the point.  We thought of having the file be named
directly after the view, but view names are allowed to include characters
that are forbidden in file names.  Before opening the file we'd have to
check the name's legality, ensure it doesn't include "../" at the beginng,
etc.  Rather than deal with that, I decided to just hash the view name, and
get a guaranteed-unique, guaranteed-legal filename for each view.

We needed a unique filename for each view because views can't share
new-zone files.  (In the prior version, this wasn't explicitly
disallowed, but it caused big ugly failure modes if you tried it.)

> Why take away the ability to remove arbitrary zones from the current
> configuration?

There are two parts to removing a zone: removing it from the currently
running server, and removing it from the configuration file so that it
doesn't come back when you restart.

The second part can only be done with zones that are in the new-zone file.
(You wouldn't want named to be directly editing named.conf.)

If you haven't done the second part, then the zone isn't really "removed",
just temporarily disabled.  I felt that if we can't do both parts, we
shouldn't do the first.  If you have a strong argument otherwise, though,
I'm listening...

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: rndc addzone/delzone in 9.7.2rc1 (was: rndc reconfig delays)

[Rob Foehl]

On Fri, 27 Aug 2010, Evan Hunt wrote:


"Non-obvious" isn't the point.  We thought of having the file be named
directly after the view, but view names are allowed to include characters
that are forbidden in file names.  Before opening the file we'd have to
check the name's legality, ensure it doesn't include "../" at the beginng,
etc.  Rather than deal with that, I decided to just hash the view name, and
get a guaranteed-unique, guaranteed-legal filename for each view.


How does this compare with the defaults for, say, the managed keys zones 
for each view?  In any case, 3bf305731dd26307.nzf isn't obvious, having 
more than one configured view will make troubleshooting more difficult for 
the uninitiated, and something like dynamic-zones.conf.viewname (where 
'viewname' is a sanitized version of such -- say all non-alphanumerics 
replaced with underscores or dashes) should be simple enough.



We needed a unique filename for each view because views can't share
new-zone files.  (In the prior version, this wasn't explicitly
disallowed, but it caused big ugly failure modes if you tried it.)


Shouldn't named explicitly check for overlap, then?  That seems in line 
with many of the other sanity checks named does during normal operation...



Why take away the ability to remove arbitrary zones from the current
configuration?


There are two parts to removing a zone: removing it from the currently
running server, and removing it from the configuration file so that it
doesn't come back when you restart.

The second part can only be done with zones that are in the new-zone file.
(You wouldn't want named to be directly editing named.conf.)

If you haven't done the second part, then the zone isn't really "removed",
just temporarily disabled.  I felt that if we can't do both parts, we
shouldn't do the first.  If you have a strong argument otherwise, though,
I'm listening...


I have a process that implements very careful zone configuration 
management and bulk zone updates, which currently triggers per-zone rndc 
reloads for existing zones followed by an rndc reconfig if zones have been 
added or removed.  The problem I've run into is that rndc reconfig is 
intolerably slow past 50,000 or so configured zones, and I'm trying to 
determine whether addzone/delzone would be a viable option.


So, I explicitly don't want named to be managing the config.  Changing the 
current server state without touching a config would be a drop-in change 
here, whereas having named manage the config removes most of the 
visibility I have into whether or not changes were successful.  The 
boolean error status available from rndc is insufficiently robust for this 
purpose, unfortunately; my process makes a number of decisions about 
whether or not it should retry an operation based on how it failed.


Of course, none of this would matter if reconfig wasn't a problem with 
this many zones, so I'm still interested in that question too... :)


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

How do I do a zone transfer of two different views

[Scott Simpson]

I have a master DNS server with two different views: "internal" and 
"external". How do I do a zone transfer of the two different views? The 
following on the slave only grabs the internal view:

view "external" {
match-clients { any; };
allow-transfer { none; };
allow-query { any; };
zone "foo.org" in {
type slave;
masters { 192.168.2.10; };
file "named.foo.org.external.slave";
};
...

because I don't know how to specify the correct view from the master.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How do I do a zone transfer of two different views

[Casey Deccio]

On Fri, Aug 27, 2010 at 11:22 PM, Scott Simpson
 wrote:
> I have a master DNS server with two different views: "internal" and
> "external". How do I do a zone transfer of the two different views? The
> following on the slave only grabs the internal view:
>

Use two TSIG keys, one for each view, to request the data.  This will
both to distinguish which view you want as well as authenticate the
transfer.  See the following for an example:

http://www.isc.org/software/bind/faq
(search for "slave server for both an internal and an external view")

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