Re: Issue with cache
On 22.11.11 12:58, Binu B Nair wrote: I am facing a very strange problem. On sending a DNS query for sabb...@direct.telstra.net I do not get a DNS response from the resolver. It shows a SERVEFAIL error. maybe because it's not valid domain name, because of the @ character. However on flushing the cache, this error subsides and the DNS look up is working fine. As per the initial analysis this is my finding: I don't even see direct.telstra.net from here. Are you a telstra.net customer? maybe it has broken NS records, and they are only visible from their network... 1. DNS lookup for the hostname was getting responded from the cache 2. On restarting named the cache got cleared In case 1 can anyone please advise why the resolver was caching a serverfail response? Maybe it's not caching thge response, but unable to find the name. Is it a bind characteristics to store all responses - positive and negative? yes. -- 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. 2B|!2B, that's a question! ___ 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.8.1-P1: 'make test' fails
Since quite a few years, I habitually run 'make test' after building BIND from sources. I'me seiing a failure with 9.8.1-P1, and wonder whether anyone else is also. Relevant log fragment is shown below. /Niall S:xfer:Tue Nov 22 11:12:07 GMT 2011 T:xfer:1:A A:System test xfer I:testing basic zone transfer functionality I:testing TSIG signed zone transfers I:reload servers for in preparation for ixfr-from-differences tests I:ns1 server reload successful I:ns2 server reload successful I:ns3 server reload successful I:ns6 server reload successful I:ns7 server reload successful I:updating master zones for ixfr-from-differences tests I:ns1 server reload successful I:ns2 server reload successful I:ns6 server reload successful I:ns7 server reload successful I:testing ixfr-from-differences yes; I:testing ixfr-from-differences master; (master zone) I:testing ixfr-from-differences master; (slave zone) I:testing ixfr-from-differences slave; (master zone) I:testing ixfr-from-differences slave; (slave zone) I:testing that incorrectly signed transfers will fail... I:initial correctly-signed transfer should succeed I:ns4 server reload successful I:failed I:unsigned transfer I:bad keydata I:partially-signed transfer I:unknown key I:incorrect key I:exit status: 1 R:FAIL E:xfer:Tue Nov 22 11:12:40 GMT 2011 ___ 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
Modify BIND ACLs on-the-fly?
Hello,
I'm looking at a BIND installation with a largish number of views, each
of which allow recursion and contain a couple of RPZ zones. Each view
has a `match-clients{}' option limiting access to the view to a very
small number of addresses. (Typically the single address of a client
with a dynamic IP address.)
When the IP of the client changes (reported and handled out-of-band),
the address_match_list in the view must be modified, which I can do with
includes scripting-magic followed by `rndc reconfig', but can I do
this more elegantly?
I was thinking along the lines of `rndc addzone', but that adds a zone
to an existing view only.
A fresh study of the latest ARM reveals nothing that I could use to
dynamically modify an ACL to place into match-clients{}, unless I've
overlooked something.
dreaming mode=on
Maybe I'm dreaming along the lines of a BIND zone updatable via DDNS,
that I can use to configure ACL content ... ;-)
zone acl-list in {
type master;
allow-query { none; };
file acl-list.db;
update-policy local;
};
view j1 in {
match-clients { sales.acl-list. ; };
};
...
$TTL 30
@ SOA acl-list. dev.null. 1 3600 1800 604800 30
NS localhost.
sales IN A 192.168.1.2
IN A 192.168.83.45
IN A 10.1.1.98
/dreaming
Any ideas or suggestions?
Regards,
-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: Modify BIND ACLs on-the-fly?
On 22/11/11 12:42, Jan-Piet Mens wrote: Maybe I'm dreaming along the lines of a BIND zone updatable via DDNS, that I can use to configure ACL content ... ;-) I've wondered about that before. Seems it would be useful for a bunch of things. ___ 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: Modify BIND ACLs on-the-fly?
Jan-Piet Mens jpmens@gmail.com wrote: Any ideas or suggestions? Not a practical one, but there are moves towards a standard nameserver control protocol: http://tools.ietf.org/html/rfc6168 http://tools.ietf.org/html/draft-dickinson-dnsop-nameserver-control http://ripe63.ripe.net/presentations/151-DNSCCM_RIPE63.pdf http://www.dnsccm.org/ Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Biscay: Northwesterly 5 or 6 at first in west, otherwise variable 4. Moderate or rough, occasionally very rough at first in west. Showers. Mainly good. ___ 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: Modify BIND ACLs on-the-fly?
On 22.11.11 13:42, Jan-Piet Mens wrote:
I'm looking at a BIND installation with a largish number of views, each
of which allow recursion and contain a couple of RPZ zones. Each view
has a `match-clients{}' option limiting access to the view to a very
small number of addresses. (Typically the single address of a client
with a dynamic IP address.)
When the IP of the client changes (reported and handled out-of-band),
the address_match_list in the view must be modified, which I can do with
includes scripting-magic followed by `rndc reconfig', but can I do
this more elegantly?
afaik your client can identify itself by TSIG instead of IP address.
of course, this requires tyour client to support TSIG
...
--
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.
WinError #98652: Operation completed successfully.
___
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: rndc flush does not work
On 11/22/2011 2:30 AM, Binu B Nair wrote: On attempting to clear cache using “rndc flush”, this does not work. However a named restart clears the cache. What could be the problem? Am I doing something wrong or have I understoos the “rndc flush” incorrectly? What makes you think that rndc flush is not flushing the cache? Provide a few more details, please. AlanC -- a...@clegg.com | acl...@infoblox.com 1.919.355.8851 signature.asc Description: OpenPGP 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
Re: Modify BIND ACLs on-the-fly?
afaik your client can identify itself by TSIG instead of IP address. of course, this requires tyour client to support TSIG ... Unfortunately the clients are dumb stub resolvers (Linux, Mac, Windows), so TSIG is not an option. -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
socket.c error in bind 9.9.0b2
When bind 9.9.0b2 starts up, the syslog shows the following messages:
Nov 22 10:18:19 nstest2 named[17190]: using default UDP/IPv6 port range: [1024,
65535]
Nov 22 10:18:19 nstest2 named[17190]: listening on IPv6 interfaces, port 53
Nov 22 10:18:19 nstest2 named[17190]: socket.c:5728: unexpected error:
Nov 22 10:18:19 nstest2 named[17190]: setsockopt(513, IPV6_V6ONLY) failed:
Invalid argument
The section of bind-9.9.0b2/lib/isc/unix/socket.c referenced in the error
message is:
#ifdef IPV6_V6ONLY
if (sock-pf == AF_INET6) {
if (setsockopt(sock-fd, IPPROTO_IPV6, IPV6_V6ONLY,
(void *)onoff, sizeof(int)) 0) {
char strbuf[ISC_STRERRORSIZE];
isc__strerror(errno, strbuf, sizeof(strbuf));
UNEXPECTED_ERROR(__FILE__, __LINE__,
setsockopt(%d, IPV6_V6ONLY)
%s: %s, sock-fd,
isc_msgcat_get(isc_msgcat,
ISC_MSGSET_GENERAL,
ISC_MSG_FAILED,
failed),
strbuf);
}
}
FIX_IPV6_RECVPKTINFO(sock); /* AIX */
#endif
I have reproduced this on Ubuntu 11.04 (Natty) and 11.10 (Oneiric) amd64. The
error does not occur with bind 9.8.1-P1. This same section of code appears in
bind-9.8.0-P1/lib/isc/unix/socket.c and is identical to the above. My systems
are operating in an IPv6/IPv4 dual-stack environment. The configuration file
named.conf.options contains listen-on-v6 { any; };. These systems seem to
respond normally to IPv6 queries. Thanks for any advice you may have about how
to troubleshoot further. Thanks.
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
Bind 9.9.0b2 inline signing...
I have opened up a Bug ticket with ISC on this - #26676, but I just wanted to
make sure that I'm not doing anything wrong that may be causing the issue.
Has anyone been able to get inline-signing to work on a static master zone
using an authoritative server?
When we manually change the Master static zone file - ualbanytest.org - the
signed and signed.jnl files are not getting an update - as shown by the
time/date stamps below (just using rndc reload).
-rw-rw-r-- 1 named root 1077 Nov 22 11:22 ualbanytest.org
-rw--- 1 named named 9415 Nov 22 11:14 ualbanytest.org.signed
-rw--- 1 named named 12041 Nov 22 11:02 ualbanytest.org.signed.jnl
The log shows the correct serial for the unsigned zone, but then pulls the
wrong signed file.
22-Nov-2011 11:25:28.314 general: info: received control channel command
'reload'
22-Nov-2011 11:25:28.314 general: info: loading configuration from
'/etc/named.conf'
22-Nov-2011 11:25:28.315 general: info: using default UDP/IPv4 port range:
[1024, 65535]
22-Nov-2011 11:25:28.315 general: info: using default UDP/IPv6 port range:
[1024, 65535]
22-Nov-2011 11:25:28.316 general: info: sizing zone task pool based on 4 zones
22-Nov-2011 11:25:28.318 general: info: zone ualbanytest.org/IN (signed):
(master) removed
22-Nov-2011 11:25:28.318 general: info: reloading configuration succeeded
22-Nov-2011 11:25:28.318 general: info: reloading zones succeeded
22-Nov-2011 11:25:28.320 general: info: zone ualbanytest.org/IN (unsigned):
loaded serial 202201
22-Nov-2011 11:25:28.320 general: info: zone ualbanytest.org/IN (signed):
loaded serial 202114 (DNSSEC signed)
22-Nov-2011 11:25:28.320 general: notice: all zones loaded
22-Nov-2011 11:25:28.320 general: notice: running
22-Nov-2011 11:25:28.320 general: info: zone ualbanytest.org/IN (signed):
reconfiguring zone keys
22-Nov-2011 11:25:28.321 general: info: zone ualbanytest.org/IN (signed): next
key event: 22-Nov-2011 11:35:28.321
22-Nov-2011 11:25:28.321 notify: info: zone ualbanytest.org/IN (signed):
sending notifies (serial 202114)
From Named.conf:
options {
directory /conf;
pid-file/var/run/named.pid;
statistics-file /var/run/named.stats;
dump-file /var/run/named.db;
version [secured];
dnssec-enable yes;
sig-validity-interval 10;
dnssec-loadkeys-interval 10;
empty-zones-enable no;
};
# DNSSEC Zone
zone ualbanytest.org {
type master;
file ualbanytest.org;
auto-dnssec maintain;
inline-signing yes;
key-directory /conf;
serial-update-method increment;
};
Has anyone gotten this to work on an authoritative (meaning that I am missing
something) or is it a real bug? I just don't want to be claiming it's a bug
if it's something that I messed up or fat fingered :)
Thanks you all in advance.
Thanks,
-Kevin
Kevin McConville
University at Albany
___
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.0b2 inline signing...
22-Nov-2011 11:25:28.320 general: notice: all zones loaded 22-Nov-2011 11:25:28.320 general: notice: running This looks to me as though you've cycled the server, which isn't currently allowed. Evan pointed out recently here that it can actually corrupt the zone... My experience is that, after changing the zone, I have to reload with the zone name explicitly given: rndc reload zonename What I'd do is remove journal and the signed version and start over. :) -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: BIND 9.8.1-P1: 'make test' fails
On Tuesday 22 November 2011 05:24:14 Niall O'Reilly wrote: Since quite a few years, I habitually run 'make test' after building BIND from sources. I'me seiing a failure with 9.8.1-P1, and wonder whether anyone else is also. Is this a manifestation of the same issue as brought up last week? https://lists.isc.org/pipermail/bind-users/2011-November/085593.html Note, Solaris in the Subject: line notwithstanding, I had the same problem under Linux. Relevant log fragment is shown below. /Niall S:xfer:Tue Nov 22 11:12:07 GMT 2011 T:xfer:1:A A:System test xfer I:testing basic zone transfer functionality I:testing TSIG signed zone transfers I:reload servers for in preparation for ixfr-from-differences tests I:ns1 server reload successful I:ns2 server reload successful I:ns3 server reload successful I:ns6 server reload successful I:ns7 server reload successful I:updating master zones for ixfr-from-differences tests I:ns1 server reload successful I:ns2 server reload successful I:ns6 server reload successful I:ns7 server reload successful I:testing ixfr-from-differences yes; I:testing ixfr-from-differences master; (master zone) I:testing ixfr-from-differences master; (slave zone) I:testing ixfr-from-differences slave; (master zone) I:testing ixfr-from-differences slave; (slave zone) I:testing that incorrectly signed transfers will fail... I:initial correctly-signed transfer should succeed I:ns4 server reload successful I:failed I:unsigned transfer I:bad keydata I:partially-signed transfer I:unknown key I:incorrect key I:exit status: 1 R:FAIL E:xfer:Tue Nov 22 11:12:40 GMT 2011 -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header ___ 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.0b2 inline signing...
Jan-Piet you get the Gold Star!!! You totally got it right! If I specify a rndc reload, the journal files never get updated and Bind loads the outdated signed file. However, if I specify an rndc reload ualbanytest.org - the changes get picked up and a journal file is created for the unsigned zone as well. -rw-rw-r-- 1 named root 1096 Nov 22 13:06 ualbanytest.org -rw--- 1 named named 772 Nov 22 13:08 ualbanytest.org.jnl -rw--- 1 named named 10523 Nov 22 13:16 ualbanytest.org.signed -rw--- 1 named named 14727 Nov 22 13:08 ualbanytest.org.signed.jnl Now, I'm guessing (hoping) that for the production release of 9.9, we can go back to using rndc reload without having to specify each individual zone? Currently in production we just use the rndc reload without specifying the zone name. Or is having to specify the zone going to be the new normal? Thanks, -Kevin Kevin McConville University at Albany -Original Message- From: Jan-Piet Mens [mailto:jpm...@gmail.com] On Behalf Of Jan-Piet Mens Sent: Tuesday, November 22, 2011 1:02 PM To: McConville, Kevin Cc: bind-users@lists.isc.org Subject: Re: Bind 9.9.0b2 inline signing... 22-Nov-2011 11:25:28.320 general: notice: all zones loaded 22-Nov-2011 11:25:28.320 general: notice: running This looks to me as though you've cycled the server, which isn't currently allowed. Evan pointed out recently here that it can actually corrupt the zone... My experience is that, after changing the zone, I have to reload with the zone name explicitly given: rndc reload zonename What I'd do is remove journal and the signed version and start over. :) -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
Fwd: DNSSEC issue, Servers Unreachable
Sorry if I used the expression bug down as it not mean necessarily that this it is a bug in anyway but probably a configuration issue. Original Message Subject: DNSSEC bug down issue, Servers Unreachable Date: Mon, 21 Nov 2011 21:45:52 -0800 To: bind-users@lists.isc.org bind-users@lists.isc.org I have checked my domain against http://www.intodns.com/bonsi.org and I am getting that everything is ok. I have signed the domain bonsi.org with dnssec key and entered the key at the https://dlv.isc.org for validation. In addition I also entered the dlv.bonsi.org. at the parent. On dlv.isc.org I am getting Servers Unreachable Servers Unreachable Severity: failure Summary: One or more servers could not be reached. When checking the status of a domain, one or more servers did not respond or did not respond correctly. If this is the initial check, all servers are requried to respond. For later checks, which simply ensure the DNSKEY is still present, at least one server must respond. Check to make certain the name servers for this zone respond over both TCP and UDP. If the servers were to be Unreachable I think I wouldn't be able to serve the domain bonsi.org and that is not the case. What could be the problem? I have dig and ping both servers and ping and dig returned ok. Port 53 and 80 are open and working fine for both servers. [user:~] root# ping ns1.bonsi.org PING ns1.bonsi.org (63.200.45.18): 56 data bytes 64 bytes from 63.200.45.18: icmp_seq=0 ttl=62 time=3.158 ms 64 bytes from 63.200.45.18: icmp_seq=1 ttl=62 time=3.367 ms 64 bytes from 63.200.45.18: icmp_seq=2 ttl=62 time=3.643 ms 64 bytes from 63.200.45.18: icmp_seq=3 ttl=62 time=3.533 ms 64 bytes from 63.200.45.18: icmp_seq=4 ttl=62 time=3.374 ms 64 bytes from 63.200.45.18: icmp_seq=5 ttl=62 time=3.456 ms [user:~] root# ping ns2.bonsi.org PING ns2.bonsi.org (63.200.45.19): 56 data bytes 64 bytes from 63.200.45.19: icmp_seq=0 ttl=62 time=3.140 ms 64 bytes from 63.200.45.19: icmp_seq=1 ttl=62 time=3.681 ms 64 bytes from 63.200.45.19: icmp_seq=2 ttl=62 time=3.438 ms 64 bytes from 63.200.45.19: icmp_seq=3 ttl=62 time=3.543 ms 64 bytes from 63.200.45.19: icmp_seq=4 ttl=62 time=3.471 ms [user:~] root# dig +tcp @63.200.45.18 ns1.bonsi.org ; DiG 9.6-ESV-R4-P3 +tcp @63.200.45.18 ns1.bonsi.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 17971 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.bonsi.org. IN A ;; ANSWER SECTION: ns1.bonsi.org. 3600IN A 63.200.45.18 ;; AUTHORITY SECTION: bonsi.org. 3600IN NS ns1.bonsi.org. bonsi.org. 3600IN NS ns2.bonsi.org. ;; ADDITIONAL SECTION: ns2.bonsi.org. 3600IN A 63.200.45.19 ;; Query time: 8 msec ;; SERVER: 63.200.45.18#53(63.200.45.18) ;; WHEN: Tue Nov 22 10:42:51 2011 ;; MSG SIZE rcvd: 95 [user:~] root# dig +tcp @63.200.45.19 ns2.bonsi.org ; DiG 9.6-ESV-R4-P3 +tcp @63.200.45.19 ns2.bonsi.org ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 20284 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns2.bonsi.org. IN A ;; ANSWER SECTION: ns2.bonsi.org. 3600IN A 63.200.45.19 ;; AUTHORITY SECTION: bonsi.org. 3600IN NS ns2.bonsi.org. bonsi.org. 3600IN NS ns1.bonsi.org. ;; ADDITIONAL SECTION: ns1.bonsi.org. 3600IN A 63.200.45.18 ;; Query time: 6 msec ;; SERVER: 63.200.45.19#53(63.200.45.19) ;; WHEN: Tue Nov 22 10:48:08 2011 ;; MSG SIZE rcvd: 95 Thanks! -- BEARTCOMMUNICATIONS Eduardo Bonsi System - Network Admin beart...@pacbell.net webmas...@beart.com ___ 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 -- BEARTCOMMUNICATIONS Eduardo Bonsi System - Network Admin beart...@pacbell.net webmas...@beart.com ___ 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
managed-keys-zone ./IN: No DNSKEY RRSIGs found for '.': success
Yesterday I started getting messages like: Nov 22 10:29:01 gemini named[28532]: managed-keys-zone ./IN: No DNSKEY RRSIGs found for '.': success Nov 22 10:53:44 titan named[15260]: managed-keys-zone ./IN/external: No DNSKEY RRSIGs found for '.': success Nov 22 10:53:54 titan named[15260]: managed-keys-zone ./IN/internal: No DNSKEY RRSIGs found for '.': success in my logs. Looks like they're showing up once per hour since they started, the same message on all my servers, both recursive and authorative. Didn't find anything useful searching for the message. Everything still seems to be working fine. Other than upgrading from 9.7.4 to 9.7.4_p1 last week nothing's changed on my side. Any thoughts on what this means and why it just started out of the blue? Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | hen...@csupomona.edu California State Polytechnic University | Pomona CA 91768 ___ 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.0b2 inline signing...
Kevin: I did something similar, using nsupdate to modify the unsigned zone
instead of a manual edit. The myzone.db, myzone.db.jnl, myzone.db.signed, and
myzone.db.signed.jnl files all get updated appropriately. rndc reload is not
necessary. It is interesting to note that the serial number in the signed zone
gets incremented more than the serial number in the unsigned zone. A dig
request for the SOA record returns the serial number from the signed zone.
To allow for this I have the following in my configuration file:
zone myzone {
type master;
file /var/lib/bind/myzone/myzone.db;
key-directory /var/lib/bind/myzone;
update-policy local;
auto-dnssec maintain;
inline-signing yes;
};
I'll give it a try with a manual edit and let you know. Jeff.
From: bind-users-bounces+spainj=countryday@lists.isc.org
[mailto:bind-users-bounces+spainj=countryday@lists.isc.org] On Behalf Of
McConville, Kevin
Sent: Tuesday, November 22, 2011 11:58 AM
To: bind-users@lists.isc.org
Subject: Bind 9.9.0b2 inline signing...
I have opened up a Bug ticket with ISC on this - #26676, but I just wanted to
make sure that I'm not doing anything wrong that may be causing the issue.
Has anyone been able to get inline-signing to work on a static master zone
using an authoritative server?
When we manually change the Master static zone file - ualbanytest.org - the
signed and signed.jnl files are not getting an update - as shown by the
time/date stamps below (just using rndc reload).
-rw-rw-r-- 1 named root 1077 Nov 22 11:22 ualbanytest.org
-rw--- 1 named named 9415 Nov 22 11:14 ualbanytest.org.signed
-rw--- 1 named named 12041 Nov 22 11:02 ualbanytest.org.signed.jnl
The log shows the correct serial for the unsigned zone, but then pulls the
wrong signed file.
22-Nov-2011 11:25:28.314 general: info: received control channel command
'reload'
22-Nov-2011 11:25:28.314 general: info: loading configuration from
'/etc/named.conf'
22-Nov-2011 11:25:28.315 general: info: using default UDP/IPv4 port range:
[1024, 65535]
22-Nov-2011 11:25:28.315 general: info: using default UDP/IPv6 port range:
[1024, 65535]
22-Nov-2011 11:25:28.316 general: info: sizing zone task pool based on 4 zones
22-Nov-2011 11:25:28.318 general: info: zone ualbanytest.org/IN (signed):
(master) removed
22-Nov-2011 11:25:28.318 general: info: reloading configuration succeeded
22-Nov-2011 11:25:28.318 general: info: reloading zones succeeded
22-Nov-2011 11:25:28.320 general: info: zone ualbanytest.org/IN (unsigned):
loaded serial 202201
22-Nov-2011 11:25:28.320 general: info: zone ualbanytest.org/IN (signed):
loaded serial 202114 (DNSSEC signed)
22-Nov-2011 11:25:28.320 general: notice: all zones loaded
22-Nov-2011 11:25:28.320 general: notice: running
22-Nov-2011 11:25:28.320 general: info: zone ualbanytest.org/IN (signed):
reconfiguring zone keys
22-Nov-2011 11:25:28.321 general: info: zone ualbanytest.org/IN (signed): next
key event: 22-Nov-2011 11:35:28.321
22-Nov-2011 11:25:28.321 notify: info: zone ualbanytest.org/IN (signed):
sending notifies (serial 202114)
From Named.conf:
options {
directory /conf;
pid-file/var/run/named.pid;
statistics-file /var/run/named.stats;
dump-file /var/run/named.db;
version [secured];
dnssec-enable yes;
sig-validity-interval 10;
dnssec-loadkeys-interval 10;
empty-zones-enable no;
};
# DNSSEC Zone
zone ualbanytest.org {
type master;
file ualbanytest.org;
auto-dnssec maintain;
inline-signing yes;
key-directory /conf;
serial-update-method increment;
};
Has anyone gotten this to work on an authoritative (meaning that I am missing
something) or is it a real bug? I just don't want to be claiming it's a bug
if it's something that I messed up or fat fingered :)
Thanks you all in advance.
Thanks,
-Kevin
Kevin McConville
University at Albany
___
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: Modify BIND ACLs on-the-fly?
afaik your client can identify itself by TSIG instead of IP address. of course, this requires tyour client to support TSIG ... On 22.11.11 15:31, Jan-Piet Mens wrote: Unfortunately the clients are dumb stub resolvers (Linux, Mac, Windows), so TSIG is not an option. no chance to run local tsig-aware proxy on them? -- 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. Due to unexpected conditions Windows 2000 will be released in first quarter of year 1901 ___ 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.8.1-P1: 'make test' fails
On 11/22/2011 3:24 AM, Niall O'Reilly wrote: Since quite a few years, I habitually run 'make test' after building BIND from sources. I'me seiing a failure with 9.8.1-P1, and wonder whether anyone else is also. All tests passed for me on FreeBSD, FWIW. -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ 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: socket.c error in bind 9.9.0b2
On 11/22/2011 11:17 AM, Spain, Dr. Jeffry A. wrote:
When bind 9.9.0b2 starts up, the syslog shows the following messages:
Nov 22 10:18:19 nstest2 named[17190]: using default UDP/IPv6 port range:
[1024, 65535]
Nov 22 10:18:19 nstest2 named[17190]: listening on IPv6 interfaces, port 53
Nov 22 10:18:19 nstest2 named[17190]: socket.c:5728: unexpected error:
Nov 22 10:18:19 nstest2 named[17190]: setsockopt(513, IPV6_V6ONLY) failed:
Invalid argument
I suspect you ran out of available file descriptors. 513 is a suspicious
number. Look to see what your file descriptor limit is. This version may
be leaking file descriptors.
Danny
The section of bind-9.9.0b2/lib/isc/unix/socket.c referenced in the error
message is:
#ifdef IPV6_V6ONLY
if (sock-pf == AF_INET6) {
if (setsockopt(sock-fd, IPPROTO_IPV6, IPV6_V6ONLY,
(void *)onoff, sizeof(int)) 0) {
char strbuf[ISC_STRERRORSIZE];
isc__strerror(errno, strbuf, sizeof(strbuf));
UNEXPECTED_ERROR(__FILE__, __LINE__,
setsockopt(%d, IPV6_V6ONLY)
%s: %s, sock-fd,
isc_msgcat_get(isc_msgcat,
ISC_MSGSET_GENERAL,
ISC_MSG_FAILED,
failed),
strbuf);
}
}
FIX_IPV6_RECVPKTINFO(sock); /* AIX */
#endif
I have reproduced this on Ubuntu 11.04 (Natty) and 11.10 (Oneiric) amd64. The
error does not occur with bind 9.8.1-P1. This same section of code appears in
bind-9.8.0-P1/lib/isc/unix/socket.c and is identical to the above. My systems
are operating in an IPv6/IPv4 dual-stack environment. The configuration file
named.conf.options contains listen-on-v6 { any; };. These systems seem to
respond normally to IPv6 queries. Thanks for any advice you may have about
how to troubleshoot further. Thanks.
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
___
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: socket.c error in bind 9.9.0b2
In message 4ecc3523.3070...@gis.net, Danny Mayer writes: On 11/22/2011 11:17 AM, Spain, Dr. Jeffry A. wrote: When bind 9.9.0b2 starts up, the syslog shows the following messages: Nov 22 10:18:19 nstest2 named[17190]: using default UDP/IPv6 port range: [1 024, 65535] Nov 22 10:18:19 nstest2 named[17190]: listening on IPv6 interfaces, port 53 Nov 22 10:18:19 nstest2 named[17190]: socket.c:5728: unexpected error: Nov 22 10:18:19 nstest2 named[17190]: setsockopt(513, IPV6_V6ONLY) failed: Invalid argument I suspect you ran out of available file descriptors. 513 is a suspicious number. Look to see what your file descriptor limit is. This version may be leaking file descriptors. Danny Known issue. The socket is already bound so the setsockopt call fails on the dup'd file descriptor. You can ignore it. A fix is already on the review queue. Mark -- 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: Bind 9.9.0b2 inline signing...
On Tue Nov 22 2011 at 20:34:46 CET, Spain, Dr. Jeffry A. wrote: I did something similar, using nsupdate to modify the unsigned zone instead of a manual edit. [...] rndc reload is not necessary. `rndc reload' never is necessary if you use DDNS to update master zones. -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
