...on Wed, Jul 01, 2015 at 09:58:52PM +1000, Mark Andrews wrote:
> Upgrade.
> 3653. [func] Create delegations for all "children" of empty zones
> except "forward first". [RT #34826]
Ugh... Seems that's in bind 9.8.5... Guess I kinda deserve
something like th
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 inc
r
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-
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
> 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 m
On Thu, Nov 29, 2012 at 7:25 PM, Matus UHLAR - fantomas
wrote:
> famous assertion failures? What system do you run the BIND on? Shouldn't
> you
> better upgrade to version that has no famous assertion failures?
Well, of course it's extremely exaggerated, sorry if I offended someone.
But crashes
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
daemon forks - if it forks once,
"expect fork" should 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.co
e metadata 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
>
> 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) ch
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 recei
>
>
> 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 re
com have TTL 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,
Al
with BIND, am I getting 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/mailma
ND reports
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
possibly expected
response of the MX record attached to *.example.com.
Regards,
Alexander,
net-me.net
On Tue, May 15, 2012 at 9:34 AM, rams 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 ge
On Fri, May 11, 2012 at 12:57 AM, Mark Andrews 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 u
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 Thu, May 10, 2012 at 11:04 PM, Axel Rau 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 internal reposito
s
are low at entropy, 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 http
On 22 Sep 2011 22:57:17 +0100, Chris Thompson 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 incremental signing wh
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 m
operly 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" wrote:
>> On Jan 11 2011, Alexander Gall wrote:
>>
>>> It appears
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
https://lists.isc.org/mailman/listi
erences?
Sorry the basic 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
d.conf' and I couldn't found the option.
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 h
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 wh
On Thu, 22 Jul 2010 07:15:25 +1000, Mark Andrews said:
> In message <19526.43429.234698.104...@hadron.switch.ch>, Alexander Gall
> writes:
>> On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen
>> said:
>>
>> > Hello,
>> > Since enabling the ro
On Wed, 21 Jul 2010 09:20:21 +0200, Gilles Massen
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 08:52:27.929 dnssec: debug 3:
d.conf and all files 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:/
SECTION:
;11.20.168.192.in-addr.arpa.IN PTR
;; AUTHORITY SECTION:
168.192.in-addr.arpa. 86400 IN SOA 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
--
Alexan
rward;
forward only;
forwarders { 192.168.20.21; };
};
zone "20.168.192.in-addr.arpa" {
type forward;
forward only;
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
On Fri, 05 Feb 2010 08:18:35 +1100, Mark Andrews 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
On 04 Feb 2010 15:39:55 +, Chris Thompson 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"
>&
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 17:36:15.
On Mon, 15 Dec 2008 15:44:39 -0800, JINMEI Tatuya / $(b...@l@C#:H(B
said:
> At Mon, 15 Dec 2008 17:18:21 +0100,
> Alexander Gall wrote:
>> > http://members.iinet.com.au/~pyard...@ihug.com.au/#%5B%5BBIND%209.5%20DNS%20Stats%5D%5D
>>
>> This looks useful, thanks.
On Fri, 12 Dec 2008 17:12:21 +1100, Peter Yardley said:
> I have written a script to collect data from the XML stats channel of a
> Bind 9.5+ DNS server. It works with Cricket and should work with MRTG
> and Cacti.
> You can get it here...
> http://members.iinet.com.au/~pyard...@ihug.com.au/
>
39 matches
Mail list logo
