Re: bind 9.9 & inline-signing issue..
Slept on this.
This morning 8+ hours later, no change.
Added a completely new record to the (unsigned) zone, updated the SOA
Serial and ran 'rndc reload':
Jan 30 09...: received control channel command 'reload'
Jan 30 09...: loading configuration from '/etc/bind/named.conf'
...
Jan 30 09...: zone test1.co.za/IN (signed): (master) removed
Jan 30 09...: reloading configuration succeeded
Jan 30 09...: reloading zones succeeded
Jan 30 09...: zone test1.co.za/IN (unsigned): loaded serial 2012013001
Jan 30 09...: zone test1.co.za/IN (signed): loaded serial 200105
(DNSSEC signed)
Jan 30 09...: all zones loaded
Jan 30 09...: running
So still broken in my opinion.
Also - I miss the creation of the "dsset-test.co.za." file :-(
I have been using the file/directory format of...
.../pri/domain.com/db.domain.com and then sticking everything associated
with that domain in that directory. Used this for over a year now and it
works well for me (organised clutter).
On Sun, 2012-01-29 at 23:37 +0200, Mark Elkins wrote:
> I agree with you. I took your example and installed bind 9.9.0b2
> I also updated my 'soa' in the unsigned...
>
> Am getting the following in my log...
> Jan 29...: zone test1.co.za/IN (unsigned): loaded serial 2012012901
> Jan 29...: zone test1.co.za/IN (signed): loaded serial 200105
> (DNSSEC signed)
>
> Also couldn't quite figure how to make this an NSEC3 signed zone from
> inception so stuck (by 'hand')
> INNSEC3PARAM 1 0 5 B9A3F38D
> into my unsigned zone. The "signed" zone seems to be NSEC though
>
> I also see...
> $TTL 0 ; 0 seconds
> TYPE65534 \# 5 ( 08467D0001 )
> TYPE65534 \# 5 ( 0896730001 )
> appearing on a secondary for this zone. What is it?
> (Yes - an unknown data type - the secondary is running bind 9.8)
>
> Next: an 'rndc sync' didn't tidy up the zones .jnl file (much to my
> disappointment)
> Lastly - how does one 'view' the 'raw' format of a zone file?
>
> I think a few examples would have helped in the documentation?
>
> On Sun, 2012-01-29 at 11:20 -0500, Howard Leadmon wrote:
> > Well after the various discussion a short while back, I decided to give
> > the inline-signing a run, and after setup I must say it did appear to do
> > what I expected. Of course anything that went that easy had to have a
> > snag, and it did, and at the moment I am wondering what I have missed so
> > figured I would post and see if anyone had any suggestions.
> >
> > After setting up a zone with DNSSEC using inline-signing, I have run into
> > the issue where if I do anything that updates the unsigned file that is
> > input into BIND, that it never seems to update the signed data it generated.
> >
> > As an example, I had serial number of 2012012701 in the test zone file, and
> > when I started named up it happily created the signed zone. So then I went
> > in and changed this serial to 2012012801, and performed an 'rndc reload' and
> > nothing, it saw the updated unsigned zone, but never kicked off an event to
> > resign the signed data it was dishing out when asked, so the changes were
> > not available. I then went and did a full restart on named, thinking maybe
> > a hard restart would make it sign, but no luck, in fact it sees the zones,
> > that the serial numbers are different, but never re-signs the served zone.
> >
> > Looking at my log I see:
> >
> >
> > named[8422]: zone leadmon.org/IN/internal (unsigned): loaded serial
> > 2012012802
> > named[8422]: zone leadmon.org/IN/internal (signed): loaded serial 2012012708
> > (DNSSEC signed)
> > named[8422]: zone leadmon.org/IN/internal (signed): receive_secure_serial:
> > unchanged
> > named[8422]: zone leadmon.org/IN/internal (signed): reconfiguring zone keys
> > named[8422]: zone leadmon.org/IN/internal (signed): next key event:
> > 29-Jan-2012 11:53:54.971
> > named[8422]: zone leadmon.org/IN/internal (signed): sending notifies (serial
> > 2012012708)
> >
> >
> > So it is seeing that the signed and unsigned zones have different serials,
> > but it's sure not picking up that I have made a change to the unsigned file,
> > and that it needs to resign the zone it's serving.
> >
> > As to my config over here, I have the following in the zone:
> >
> > zone "leadmon.org" {
> > type master;
> > file "master/leadmon.org/db.leadmon.org-internal";
> > key-directory "keys";
> > allow-transfer {
> > primary_servers;
> > };
> > auto-dnssec maintain;
> > inline-signing yes;
> > };
> >
> >
> > Have I missed any additional commands I need to make this play correctly,
> > or is something broken here that I have run into?
> >
> >
> >
> > ---
> > Howard Leadmon
> >
> >
> >
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
>
Re: Detailed Log Analysis based on rndc stats!!
In message , Shiva Raman writes: > Hi Peter > > Thanks a lot for your reply. I had enabled query-errors with debug level 2 > in my bind logging, now i am able to log all SERVFAIL related error logs in > query-errors.log. But i am unable to log the NXDOMAIN error logs . NXDOMAIN is not a error. It is a *normal* response code in a well running system. Asking to log NXDOMAIN is like asking to log every positive answer. >Referring to Bind documentation, i enabled delegation-only option(which > Logs queries that have returned NXDOMAIN as the result of a delegation-only > zone or a delegation-only statement in a hint or stub zone declaration) , > but this also not logging the NXDOMAIN errors. Kindly guide me whether any > additional parameters to be enabled in query-errors to log NXDOMAIN also. delegation-only does *not* log normal NXDOMAIN responses. It logs answers that are *forced* to NXDOMAIN. > Regards > > Shiva Raman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Detailed Log Analysis based on rndc stats!!
Hi Peter
Thanks a lot for your reply. I had enabled query-errors with debug level 2
in my bind logging, now i am able to log all SERVFAIL related error logs in
query-errors.log. But i am unable to log the NXDOMAIN error logs .
Referring to Bind documentation, i enabled delegation-only option(which
Logs queries that have returned NXDOMAIN as the result of a delegation-only
zone or a delegation-only statement in a hint or stub zone declaration) ,
but this also not logging the NXDOMAIN errors. Kindly guide me whether any
additional parameters to be enabled in query-errors to log NXDOMAIN also.
Regards
Shiva Raman
On Tue, Jan 17, 2012 at 9:11 PM, Peter Andreev wrote:
>
> 2012/1/17 Shiva Raman
>
>> Hi All
>>
>> i am running Bind version 9.8.1 as an Authoritative Name server. From
>> the rndc.stats , i observe that there are some query failures happening
>> in the server. I am trying to get a detailed information of this query
>> failures, but the current logging options is not allowing me to get a
>> detailed
>> report on the reason of failure. I tried enabling detailed logs, but that
>> is also not providing me which all queries failed with NXDOMAIN ,
>> SERVFAILetc.
>>
>> Please find the ouptut of named.stats and Logging options enabled in
>> named.conf
>>
>> Output of /chroot/named/conf/named.stats
>> --
>>
>> +++ Statistics Dump +++ (1326803941)
>> ++ Incoming Requests ++
>>75808 QUERY
>> ++ Incoming Queries ++
>>75786 A
>> 22 PTR
>> ++ Outgoing Queries ++
>> [View: default]
>> 7374 A
>>13410 NS
>> 97 PTR
>> [View: _bind]
>> ++ Name Server Statistics ++
>>75808 IPv4 requests received
>>75781 requests with ADNS(0) received
>>75019 responses sent
>>75003 responses with ADNS(0) sent
>> 2848 queries resulted in successful answer
>>72340 queries resulted in authoritative answer
>> 2239 queries resulted in non authoritative answer
>> 440 queries resulted in SERVFAIL
>>71731 queries resulted in NXDOMAIN
>> 3466 queries caused recursion
>> 789 duplicate queries received
>> ++ Zone Maintenance Statistics ++
>> ++ Resolver Statistics ++
>> [Common]
>> [View: default]
>>20881 IPv4 queries sent
>> 5283 IPv4 responses received
>> 111 NXDOMAIN received
>> 2533 SERVFAIL received
>>16195 query retries
>>15598 query timeouts
>> 450 IPv4 NS address fetches
>>6 IPv4 NS address fetch failed
>> 4226 queries with RTT < 10ms
>> 17 queries with RTT 10-100ms
>> 869 queries with RTT 100-500ms
>> 82 queries with RTT 500-800ms
>> 37 queries with RTT 800-1600ms
>> 52 queries with RTT > 1600ms
>> [View: _bind]
>> ++ Cache DB RRsets ++
>> [View: default]
>> 72 A
>> 24 NS
>>5 CNAME
>>5 NXDOMAIN
>> [View: _bind (Cache: _bind)]
>> ++ Socket I/O Statistics ++
>>20886 UDP/IPv4 sockets opened
>>4 TCP/IPv4 sockets opened
>>20883 UDP/IPv4 sockets closed
>> 3910 TCP/IPv4 sockets closed
>>2 UDP/IPv4 socket bind failures
>>20881 UDP/IPv4 connections established
>> 3911 TCP/IPv4 connections accepted
>> ++ Per Zone Query Statistics ++
>> --- Statistics Dump --- (1326803941)
>>
>>
>> Logging options in /etc/named.conf
>>
>>
>>
>> // Logging options
>> logging {
>> // logging option for named process
>> channel "default_debug" {
>> file "/logs/named.log" versions 10 size 500m;
>> print-time yes;
>> print-category yes;
>> severity dynamic;
>> };
>>
>> channel "queries" { // logging option for queries to
>> named
>> file "/logs/query.log" versions 20 size 500m;
>> print-time yes;
>> print-category yes;
>> severity dynamic;
>> };
>>
>> category default { "default_debug"; };
>> category queries { null; }; // comment this line to log queries
>> category queries { "queries"; };// uncomment this to log queries
>> category config { "default_debug"; };
>> category security { "default_debug"; };
>> category network { "default_debug"; };
>> category lame-servers { null; };
>> category general { null; };
>> category edns-disabled { null; };
>> };
>>
>>
>> --
RE: bind 9.9 & inline-signing issue..
> After setting up a zone with DNSSEC using inline-signing, I have run into the > issue where if I do anything that updates the unsigned file that is input > into BIND, that it never seems to update the signed data it generated. > As an example, I had serial number of 2012012701 in the test zone file, and > when I started named up it happily created the signed zone. So then I went > in and changed this serial to 2012012801, and performed an 'rndc reload' and > nothing, it saw the updated unsigned zone, but never kicked off an event to > resign the signed data it was dishing out when asked, so the changes were not available. I have been using inline signing successfully, but am using a different method to make changes to the unsigned data. My zone configuration contains "update-policy local;" and I have been using "nsupdate -l" to make changes to the unsigned zone. Nsupdate automatically increments the serial number on the SOA record in the unsigned zone. The signed zone typically has a different and higher serial number due to signing activity that occurs automatically, e.g. resigning a record with an expired signature. With regard to "rndc reload" not working for you, see https://lists.isc.org/pipermail/bind-users/2011-November/085739.html. Per that message, try "rndc reload leadmon.org". Also verify that the UID under which the named process is running is the owner of the various zone data and journal files. Jeffry A. Spain Network Administrator Cincinnati Country Day School ___ 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: bind 9.9 & inline-signing issue..
I agree with you. I took your example and installed bind 9.9.0b2
I also updated my 'soa' in the unsigned...
Am getting the following in my log...
Jan 29...: zone test1.co.za/IN (unsigned): loaded serial 2012012901
Jan 29...: zone test1.co.za/IN (signed): loaded serial 200105
(DNSSEC signed)
Also couldn't quite figure how to make this an NSEC3 signed zone from
inception so stuck (by 'hand')
IN NSEC3PARAM 1 0 5 B9A3F38D
into my unsigned zone. The "signed" zone seems to be NSEC though
I also see...
$TTL 0 ; 0 seconds
TYPE65534 \# 5 ( 08467D0001 )
TYPE65534 \# 5 ( 0896730001 )
appearing on a secondary for this zone. What is it?
(Yes - an unknown data type - the secondary is running bind 9.8)
Next: an 'rndc sync' didn't tidy up the zones .jnl file (much to my
disappointment)
Lastly - how does one 'view' the 'raw' format of a zone file?
I think a few examples would have helped in the documentation?
On Sun, 2012-01-29 at 11:20 -0500, Howard Leadmon wrote:
> Well after the various discussion a short while back, I decided to give
> the inline-signing a run, and after setup I must say it did appear to do
> what I expected. Of course anything that went that easy had to have a
> snag, and it did, and at the moment I am wondering what I have missed so
> figured I would post and see if anyone had any suggestions.
>
> After setting up a zone with DNSSEC using inline-signing, I have run into
> the issue where if I do anything that updates the unsigned file that is
> input into BIND, that it never seems to update the signed data it generated.
>
> As an example, I had serial number of 2012012701 in the test zone file, and
> when I started named up it happily created the signed zone. So then I went
> in and changed this serial to 2012012801, and performed an 'rndc reload' and
> nothing, it saw the updated unsigned zone, but never kicked off an event to
> resign the signed data it was dishing out when asked, so the changes were
> not available. I then went and did a full restart on named, thinking maybe
> a hard restart would make it sign, but no luck, in fact it sees the zones,
> that the serial numbers are different, but never re-signs the served zone.
>
> Looking at my log I see:
>
>
> named[8422]: zone leadmon.org/IN/internal (unsigned): loaded serial
> 2012012802
> named[8422]: zone leadmon.org/IN/internal (signed): loaded serial 2012012708
> (DNSSEC signed)
> named[8422]: zone leadmon.org/IN/internal (signed): receive_secure_serial:
> unchanged
> named[8422]: zone leadmon.org/IN/internal (signed): reconfiguring zone keys
> named[8422]: zone leadmon.org/IN/internal (signed): next key event:
> 29-Jan-2012 11:53:54.971
> named[8422]: zone leadmon.org/IN/internal (signed): sending notifies (serial
> 2012012708)
>
>
> So it is seeing that the signed and unsigned zones have different serials,
> but it's sure not picking up that I have made a change to the unsigned file,
> and that it needs to resign the zone it's serving.
>
> As to my config over here, I have the following in the zone:
>
> zone "leadmon.org" {
> type master;
> file "master/leadmon.org/db.leadmon.org-internal";
> key-directory "keys";
> allow-transfer {
> primary_servers;
> };
> auto-dnssec maintain;
> inline-signing yes;
> };
>
>
> Have I missed any additional commands I need to make this play correctly,
> or is something broken here that I have run into?
>
>
>
> ---
> Howard Leadmon
>
>
>
> ___
> 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
--
. . ___. .__ Posix Systems - (South) Africa
/| /| / /__ m...@posix.co.za - Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496
smime.p7s
Description: S/MIME cryptographic 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
bind 9.9 & inline-signing issue..
Well after the various discussion a short while back, I decided to give
the inline-signing a run, and after setup I must say it did appear to do
what I expected. Of course anything that went that easy had to have a
snag, and it did, and at the moment I am wondering what I have missed so
figured I would post and see if anyone had any suggestions.
After setting up a zone with DNSSEC using inline-signing, I have run into
the issue where if I do anything that updates the unsigned file that is
input into BIND, that it never seems to update the signed data it generated.
As an example, I had serial number of 2012012701 in the test zone file, and
when I started named up it happily created the signed zone. So then I went
in and changed this serial to 2012012801, and performed an 'rndc reload' and
nothing, it saw the updated unsigned zone, but never kicked off an event to
resign the signed data it was dishing out when asked, so the changes were
not available. I then went and did a full restart on named, thinking maybe
a hard restart would make it sign, but no luck, in fact it sees the zones,
that the serial numbers are different, but never re-signs the served zone.
Looking at my log I see:
named[8422]: zone leadmon.org/IN/internal (unsigned): loaded serial
2012012802
named[8422]: zone leadmon.org/IN/internal (signed): loaded serial 2012012708
(DNSSEC signed)
named[8422]: zone leadmon.org/IN/internal (signed): receive_secure_serial:
unchanged
named[8422]: zone leadmon.org/IN/internal (signed): reconfiguring zone keys
named[8422]: zone leadmon.org/IN/internal (signed): next key event:
29-Jan-2012 11:53:54.971
named[8422]: zone leadmon.org/IN/internal (signed): sending notifies (serial
2012012708)
So it is seeing that the signed and unsigned zones have different serials,
but it's sure not picking up that I have made a change to the unsigned file,
and that it needs to resign the zone it's serving.
As to my config over here, I have the following in the zone:
zone "leadmon.org" {
type master;
file "master/leadmon.org/db.leadmon.org-internal";
key-directory "keys";
allow-transfer {
primary_servers;
};
auto-dnssec maintain;
inline-signing yes;
};
Have I missed any additional commands I need to make this play correctly,
or is something broken here that I have run into?
---
Howard Leadmon
___
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
