Re: RHEL, Centos, Fedora rpm vs ISC bind versions

[Michael Hoskins (michoski)]

-Original Message-

From: Drunkard Zhang 
Date: Sunday, July 15, 2012 5:29 PM
To: Eivind Olsen 
Cc: "" 
Subject: Re: RHEL, Centos, Fedora rpm vs ISC bind versions

>2012/7/16 Eivind Olsen :
>> Den 15. juli 2012 kl. 16:57 skrev Benny Pedersen :
>>
>>> change to gentoo/funtoo ?
>>
>> Some might prefer to run the same Linux distribution on all their
>>servers, changing to something like Gentoo just to get BIND running
>>seems a bit overkill.
>>
>For critical services, I advice you to run different distros of Linux,
>or at least different version of same distro. And fixing of bind in
>Gentoo is extremly timely, generally within 48 hours when a bug
>confirmed.
>
>Debug is easy too, you can easily add RESTRICT="-strip" to disable
>final strip, so you got debugable binaries. ;)

hmm, sure...  but if you're going for genetic diversity, why not throw BSD
into the mix?  or run dedicated appliances with vendor support (you did
say critical)?  don't forget to change the hardware architecture.

oh, wait, that wasn't the point of the original post...  so suggestions to
change OS or platform aren't really useful here and sort of hijack the
thread.

since no one's said it publicly to the OP yet -- thanks.  each OS will
have its zealots, and diversity certainly makes sense in some scenarios...
 but i appreciate the effort and feel such things add value for the BIND
community.

ps: we build our own packages to provide the (in)famous "ITIL DSL"...
however, doing so requires time and expertise.  the fact someone offered
up their resources to help BIND users (it might not meet YOUR need, but
it's useful for some) should really be recognized and not used as an
advocacy podium best whipped in $os-users.

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

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

Re: Weird stuff with one host... :-S

[Jan-Piet Mens]

> no A record, but if I log into my  server, where I have:

Is your name server configured to use views? Looks to me as though a
view is "hiding" your answer.

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

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

Re: Weird stuff with one host... :-S

[Michelle Konzack]

Hello Barry,

Am 2012-07-16 00:18:37, hacktest Du folgendes herunter:
> In article ,
>  Michelle Konzack  wrote:
> > ANY hosts are working from any workstations/servers except 
> > on .
> Views?

No, it is a Debian standard installation and I have nothing special.

Can "views" be configured by Host/IP?

I think, it was only possibel by "zone"

And all of the workstations  and  servers  are  in  the  same  subdomain
 which make the error realy bizzar... because
I have only added the new host to the config, updated  the  serialnumber
and reloaded the zone.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux
   Internet Service Provider, Cloud Computing


itsystems@tdnet Jabber  linux4miche...@jabber.ccc.de
Owner Michelle Konzack

Gewerbe Strasse 3   Tel office: +49-176-86004575
77694 Kehl  Tel mobil:  +49-177-9351947
Germany Tel mobil:  +33-6-61925193  (France)

USt-ID:  DE 278 049 239

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Possible dnssec-signzone re-sign bug with former orphan glue

[Paul Wouters]

Hi,

When using dnssec-signzone manually to sign a zone, I think there is a
case where it does not drop the RRSIGs when I think it should. Image
that dnssec-signzone is used with the old signed zone's RRSIG/NSEC*
data, along with an updated "unsigned" zone.

Let's say we are example.com. At T=0 we have in our signed zone:

foo.example.com. IN NS ns1.foo.example.com.
foo.example.com. IN NS ns2.foo.example.com.
ns1.foo.example.com. IN A 1.2.3.4
ns2.foo.example.com. IN A 1.2.3.4

The NS RRset is signed. The A records are not.

At T=1, the delegation for foo.example.com is removed, but (to prevent
other domains depending on those name servers to not die) the A records
are retained. Since this is now orphaned glue, the A records get signed.

At T=2, the delegation for foo.example.com is restored. The input zone
for dnssec-signzone receives the RRSIGs for the A record, and it should
drop these, but instead retains them. I am not sure what happens when
they would fall below the re-sign treshold.

I believe the correct behaviour should be for dnssec-signzone to drop
the RRSIGs of the A records when the delegation got restored.

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

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

Re: recursive-clients recommended values

[Scott Bertilson]

One thing that has always been a mystery to me is what the difference is
between the hard and soft limits on recursion - i.e. the default limit on
recursion is 1000 which means that the soft limit is not in effect.  When
the limit is reached, the oldest query is always dropped, but without a
soft limit, the most recent query is also dropped.  When recursive-clients
is set above 1000, the soft query limit is set to 100 less than the
recursive-clients value and the most recent query is allowed to continue as
long as the hard limit is not exceeded.

I have never found anything in the documentation that describes this
behavior or explains why the soft limit defaults to disabled.  It has
always seemed to me that it is more desirable to allow the most recent
query to proceed whenever possible, hopefully allowing named to keep doing
recursion for those sites for which it can while dumping queries for those
which are slower in responding, hopefully allowing some queries to succeed
during a network brownout or loss of connectivity.

Scott

On Mon, Jul 16, 2012 at 12:14 AM, blrmaani  wrote:

> I
>
> On Thursday, July 12, 2012 3:49:27 AM UTC-7, Niall O'Reilly wrote:
> > On 12 Jul 2012, at 03:21, blrmaani wrote:
> >
> > > I searched earlier posts but noticed that people are recommending
> it to just increase it to suppress the errors in log.
> > >
> > > Any pointers on this?
> >
> >   If it's set too low for your normal operating circumstances,
> you do need to increase it.
> >   I've never needed to do this, as the default values just works
> for me.
> >
> >   In abnormal operating circumstances, it's probably neither
> posssible, nor useful to try, to eliminate
> >   the log messages. See, for example,
> https://lists.isc.org/pipermail/bind-users/2009-August/077589.html.
> >
> >   Best regards,
> >   Niall O'Reilly
>
> I saw a related post and response in other group.
> http://osdir.com/ml/network.dns.bind.user/2003-07/msg00042.html
>
> I am still trying to figure out the '90 second' part...
>
> thanks
> Blr
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Weird stuff with one host... :-S

[SM]

At 06:31 16-07-2012, Michelle Konzack wrote:

Can "views" be configured by Host/IP?


"A client matches a view if its source IP address matches the 
address_match_list of the view's match-clients clause and its 
destination IP address matches the address_match_list of the view's 
match-destinations clause".  See example at 
http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch06.html#id2590162


Regards,
-sm 


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

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