Hi,
I have an internal bind server that has several forward zones pointing to
other internal name servers that carry reverse zones for rfc1918 networks
we are using in our networks (let's say something like 0.20.10.in-addr.arpa).
This works fine until I either set empty-zones-enable yes; or
the same ns1/ns2, instead of advising each user to add ns3..nsX to their
parent zones.
Thanks,
Alexander Gurvitz,
net-me.net
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users
Linh,
From my personal experience - BIND have lots of such bugs.
Upgrade to the latest version (minor one - 9.8.4-P1, not 9.9.2) and see if
the error reappears.
If yes, report it to bind9-b...@isc.org (if the bug is not reproducible
anyway even on 9.8.3-P1, I'd report it too).
Alexander Gurvitz
I don't think it's wise to respawn named without knowing why it crashed.
This could lead to repeated crashed and system overload.
1. I have a system whose only reason to exist is running bind, once bind
stops I don't mind the whole system overload, crash or go to hell.
2. When I've seen that my
be specified, and if a daemon forks twice,
it should be expect daemon. Then upstart will wait for that forkings and
will monitor the final PID).
Thanks in advance,
Alexander Gurvitz,
net-me.net
P.S My /etc/init/bind.conf:
start on runlevel [2345]
stop on runlevel [!2345]
pre-start script
Carsten,
The script in my original question (it's in the P.S. at the bottom of my
first mail) seem to work for me. It does not cover all the extra logic of
the ubuntu default init.d/bind9, but I personally don't need that (ubuntu
script may update resolv.conf, and also checks if there's a network
and should remove the key
and all the signatures at that time.
You don't need nsupdate nor update-policy for that.
Regards,
Alexander Gurvitz,
net-me.net
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
That paragraph from 4.1.4 is just plain wrong and following it will
lead to cached data that can't be validated once retrieved.
Lets say that all data in the zone has a TTL of 3600.
At T - 3500 you have retrieved the DNSKEY while validating a MX RRset.
At T - 100 you lookup a A record and
Mark,
3282. [bug] Restrict the TTL of NS RRset to no more than that
of the old NS RRset when replacing it.
[RT #27792] [RT #27884]
TTL of the old NS RRset here means the current remaining TTL,
or the original TTL value as received
3282. [bug] Restrict the TTL of NS RRset to no more than that
of the old NS RRset when replacing it.
[RT #27792] [RT #27884]
Just to clarify - does this rule applies also while replacing parent NS
records
with (more credible) child
it right ?
Thanks in advance,
Alexander Gurvitz,
net-me.net
___
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
of 3600.
Thus each hour ns.isp.com queries ns.OLDprovider.net,
with each query gets new NS record, and... refreshes the NS TTL ?
Will ns.isp.com EVER query ns.NEWprovider.net ?
I'd be happy to know how BIND behaves, but also
how other servers may behave in this case.
Regards,
Alexander Gurvitz,
net
there.
Alexander Gurvitz,
net-me.net
___
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
Hi.
TTL returned by YOUR zone authoritative server will (at least should) be
preferred by caches.
Matt Larson from verisign explained on these:
http://www.merit.edu/mail.archives/nanog/2004-07/msg00255.html
Regards,
Alexander Gurvitz,
net-me.net
of the MX record attached to *.example.com.
Regards,
Alexander,
net-me.net
On Tue, May 15, 2012 at 9:34 AM, rams brames...@gmail.com wrote:
Hi,
I have NS record points a record [A/] which is falls into wildcard . But
when I query for NS record against bind, we are not getting these records
On Fri, May 11, 2012 at 12:57 AM, Mark Andrews ma...@isc.org wrote:
What random device used for ?
... I don't get why signing a zone requires any randomness.
It doesn't for RSA. However DSA does require randomness.
Does BIND really needs that entropy, and how much ?
Yes, if you are
, and BIND default random-device is /dev/random,
and it (the device) blocks when there's no entropy available.
Does BIND really needs that entropy, and how much ?
Regards,
Alexander Gurvitz,
net-me.net
___
Please visit https://lists.isc.org/mailman
On Thu, May 10, 2012 at 11:04 PM, Axel Rau axel@chaos1.de wrote:
Did you delete it manually (at 2012-05-07T14:55:02.569706) ?
Yes; i.e. my script.
If so, maybe it's still in the zone because BIND doesn't know the timing
metadata anymore ?
I thought that would be in the journal or
Hello,
Multiple zones with a single key - is possible with BIND ?
Regards,
Alexander Gurvitz,
net-me.net
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
On 22 Sep 2011 22:57:17 +0100, Chris Thompson c...@cam.ac.uk said:
There was some correspondence last year about this warning message, but
this seems to be caused by something new.
Back then it was due to a bug in dnssec-signzone that caused NSEC3
records to remain in the zone during
I have a signed zone for which dnssec-signzone and named-checkzone of
BIND 9.8.0-P4 emit the message in the subject several times. This
appears to happen in loadnode() defined in lib/dns/rbtdb.c and has
something to do with an auxiliary tree for NSEC, whatever exactly
that is. It doesn't tell me
my
tools could properly handle turning on DNSSEC for an existing zone,
which involves having to wait for cached DNSKEY NODATA to expire from
caches before adding the DS.
On 11/01/11 4:52 PM, Chris Thompson c...@cam.ac.uk wrote:
On Jan 11 2011, Alexander Gall wrote:
It appears that NODATA
It appears that NODATA responses for qtype=DNSKEY are not cached if
DNSSEC validation is enabled (tested with 9.7.2-P3). What is the
rationale behind this?
--
Alex
___
bind-users mailing list
bind-users@lists.isc.org
questions... it's just because I think it's a good idea
share my worries in this case.
[]s
Alexander
Brazil
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
I don't think the standard BIND RPMs for the above have support for
'managed-keys' as the highest version they go is up to BIND 9.3.
Thanks Antonio and Kevin.
My systems are using Bind 9.4.
I'm going to upgrade to 9.7 as you suggested.
Thank you!
[]s
Alexander
Brazil
.
But despite that I think I'm doing something really stupid, but I can't
find what.
And, yes, I put that option into named.conf file, just below options
block:
options {
# some options here
};
managed-keys {
# my key
};
...
[]s
Alexander
Brazil
On Thu, 22 Jul 2010 07:15:25 +1000, Mark Andrews ma...@isc.org said:
In message 19526.43429.234698.104...@hadron.switch.ch, Alexander Gall
writes:
On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen gilles.mas...@restena.lu
said:
Hello,
Since enabling the root TA in my resolver, I keep
On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen gilles.mas...@restena.lu
said:
Hello,
Since enabling the root TA in my resolver, I keep seeing from time to time:
21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: .
SOA: attempting insecurity proof
21-Jul-2010
;
forwarders { 192.168.20.21; };
};
Any hint? Why does this work just with host? Thanks!
--
Alexander Fortin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
localhost.
root.localhost. 1 604800 86400 2419200 86400
;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Apr 2 16:24:36 2010
;; MSG SIZE rcvd: 94
--
Alexander Fortin
Studio Synthesis srl
Network System Administrator
Via Callegari 10, Brescia - (+39)030/8336089
http
therein included, then check again.
(Make sure your zone db file serial number is incremented on every change.)
Then rndc reload when needed...etc..
--
Alexander Fortin
Studio Synthesis srl
Network System Administrator
Via Callegari 10, Brescia - (+39)030/8336089
http://www.studiosynthesis.biz
On Fri, 05 Feb 2010 08:18:35 +1100, Mark Andrews ma...@isc.org said:
In message 19306.52059.975062.462...@hadron.switch.ch, Alexander Gall
writes:
All of those are NSEC3-agnostic. They should not do any DNSSEC
processing for the ch zone, because they don't support algorithm #7.
Yes
Our authoritative servers for the signed TLD ch (NSEC3, no opt-out)
are receiving queries whose qnames are the NSEC3 hashed owner names of
existing delegeations. I suspect that this is a BIND issue (see
below), hence my post to this list.
What I'm seeing is stuff like this:
03-Feb-2010
On 04 Feb 2010 15:39:55 +, Chris Thompson c...@cam.ac.uk said:
On Feb 4 2010, Alexander Gall wrote:
Of the 60 sources in my sample,
26 responded to version queries. All of them identified themselves as
some version of BIND
5 9.5.0-P2
3 9.4.2-P2.1
3 9.4.2-P2
3 9.4.2-P1
3 9.3.4-P1
34 matches
Mail list logo
