Re: Logging question about message 'update-security: error: client update denied'
In message
, Josh
Nielsen writes:
I have a message that has been showing up in my master DNS server's log
over the past few weeks and I am wondering if I can find more verbose
specifics from debugging messages in BIND somehow.
The messsage looks like this:
May 16 10:52:16 dns01 named[2591]: 16-May-2016 10:52:16.844
update-security: error: client 10.20.0.101#34148: update 'my.domain/IN'
denied
On 17.05.16 07:24, Mark Andrews wrote:
It a UPDATE request being denied. It will be some process other
than named sending the request unless you have configured named to
forward updates.
In the best of worlds every machine would be updating its own PTR
records and keep its own addresses in the DNS up to date.
depends on the idealness of the world, but I personally don't like allowing
clients to update their DNS records, imho the DHCP server should do those
changes if it assigne the client an IP address
Master (10.20.0.110):
zone "my.domain" in {
type master;
file "db.my.domain";
allow-transfer {
10.20.0.100/32;
10.20.0.101/32;
};
allow-update {
key "xcat_key";
};
notify yes;
also-notify {10.20.0.100; 10.20.0.101;};
};
apparently the client who asks for update does not know the "xcat_key".
...many windows machines tend to register their name in DNS (it's
on by default in netowrk settings).
--
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.
"They say when you play that M$ CD backward you can hear satanic messages."
"That's nothing. If you play it forward it will install Windows."
___
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: Forward zone not working
> > > >Ideally every machine should be registering its own PTR record in the > > >DNS and addresses without machines shouldn't have PTR records. > > >The only reason ISP did this is that they were too lazy to manage PTR > > >records for their customers. > > > > And because no ISP wants "you.suck.isp.com" to show up in their DNS. > > > > Same fight, different address space. > > Agreed. Nice in theory, not going to happen in practice for the ISP where I'm > working. Ditto here, great feature for smaller shop but not an ISP for a number of reasons. I would also add based on business perspective sometimes "lazy" is consumer or market driven and can't be simply dismissed. How popular would a brand new 60" television be without a remote control? Regards, John > > Steinar Haug, Nethelp consulting, sth...@nethelp.no > ___ > 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 > This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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: Forward zone not working
On 17 May 2016 at 09:29, Woodworth, John R wrote: > > > > > >Ideally every machine should be registering its own PTR record in the > > > >DNS and addresses without machines shouldn't have PTR records. > > > >The only reason ISP did this is that they were too lazy to manage PTR > > > >records for their customers. > > > > > > And because no ISP wants "you.suck.isp.com" to show up in their DNS. > > > > > > Same fight, different address space. > > > > Agreed. Nice in theory, not going to happen in practice for the ISP > where I'm working. > > > Ditto here, great feature for smaller shop but not an ISP for a number of > reasons. > > I would also add based on business perspective sometimes "lazy" is > consumer or market > driven and can't be simply dismissed. How popular would a brand new 60" > television be > without a remote control? > > Indeed. When a business appears "too lazy" to do a thing you want them to do, what that really means is that there is no business case that makes it worth their while to spend the money on doing it. ___ 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: Logging question about message 'update-security: error: client update denied'
Okay, yeah I am running DHCP on the same server so I'll check its settings. Thanks! On Mon, May 16, 2016 at 6:08 PM, Matthew Pounsett wrote: > > > On 16 May 2016 at 19:03, Josh Nielsen wrote: > >> Thank you for the response Mark. I'm still a little confused at what this >> might mean though. Clearly the originating address is my slave DNS server >> (every single one of the messages say "error: client 10.20.0.101"). >> >> Are you saying that some process other than named on the same server >> (10.20.0.101) is responsible for these messages (and is there a 'for >> instance' of what could do such a thing?), or that somehow other hosts are >> relaying their update requests (again: from what possible processes?) >> through my slave dns server? What can I look for to figure this out on my >> network? >> > > Your DHCP daemon would be one thing that could be generating those > messages. Often it's configured to update the DNS with the addresses it's > handing out (either forward, reverse, or both). > ___ 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
Trouble with option managed-keys
Hi all,
I have a problem with DNSSEC and I dont find a solution. Maybe someone can help
me.
My intention is to run a bind which acts as DNSSEC enabled resolver for my
internal LAN. This runs on a VirtualBox instance with OpenBSD 5.9. I got a
precompiled package from OpenBSD, version is 9.10.3-P3.
Configuring my named, I mostly followed a howto from Calomel.org:
https://calomel.org/dns_bind.html
This is my named.conf:
root@bsd59n:/var/named/etc# egrep -v '^ *#|^ *$|^\/\/' named.conf
acl clients {
127.0.0.0/8;
192.168.21.0/24;
::1;
};
options {
version ""; // remove this to allow version queries
listen-on{ 127.0.0.1; 192.168.21.101; };
listen-on-v6 { none; };
empty-zones-enable yes;
allow-query { clients; };
allow-recursion { clients; };
allow-transfer { none; };
include "/etc/root_trusted_key";
dnssec-enable yes;
dnssec-validation yes;
};
logging {
category lame-servers { null; };
};
zone "." {
type hint;
file "etc/root.hint";
};
zone "localhost" {
type master;
file "standard/localhost";
allow-transfer { localhost; };
};
zone "127.in-addr.arpa" {
type master;
file "standard/loopback";
allow-transfer { localhost; };
};
As my named is running in a chroot jail, /etc/root_trusted_key is
/var/named/etc/root_trusted_key in reality.
root@bsd59n:/var/named/etc# root_trusted_key
managed-keys {
"." initial-key 257 3 8
"AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ";
};
root_trusted_key was generated as Calomel howto describes.
Now, when I try to start named with that config, I get a courious error message:
root@bsd59n:/var/named/etc# /usr/local/sbin/named -t /var/named -u _bind -U 4 -g
17-May-2016 21:53:14.644 starting BIND 9.10.3-P3 -t /var/named -u
_bind -U 4 -g
17-May-2016 21:53:14.644 built with '--enable-shared' '--enable-filter-'
'--enable-threads' '--with-libt
ool' '--without-readline' '--with-python=/usr/local/bin/python2.7'
'--prefix=/usr/local' '--sysconfdir=/etc'
'--mandir=/usr/local/man' '--infodir=/usr/local/info' '--localstatedir=/var'
'--disable-silent-rules' '--di
sable-gtk-doc' 'CC=cc' 'CFLAGS=-O2 -pipe'
17-May-2016 21:53:14.644
17-May-2016 21:53:14.644 BIND 9 is maintained by Internet Systems Consortium,
17-May-2016 21:53:14.644 Inc. (ISC), a non-profit 501(c)(3) public-benefit
17-May-2016 21:53:14.644 corporation. Support and training for BIND 9 are
17-May-2016 21:53:14.644 available at https://www.isc.org/support
17-May-2016 21:53:14.644
17-May-2016 21:53:14.645 found 2 CPUs, using 2 worker threads
17-May-2016 21:53:14.645 using 2 UDP listeners per interface
17-May-2016 21:53:14.648 using up to 4096 sockets
17-May-2016 21:53:14.681 loading configuration from '/etc/named.conf'
17-May-2016 21:53:14.683 /etc/root_trusted_key:1: unknown option 'managed-keys'
17-May-2016 21:53:14.686 loading configuration: failure
17-May-2016 21:53:14.686 exiting (due to fatal error)
But named documentation and "man named.conf" both say that managed-keys were a
valid option.
So what's wrong here? Thanks in advance for any help.
Thomas Hluchnik
signature.asc
Description: This is a digitally signed message part.
___
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: Trouble with option managed-keys
"managed-keys" is not a config option, try moving it outside the option
stanza, eg
options {
version ""; // remove this to allow version queries
listen-on{ 127.0.0.1; 192.168.21.101; };
listen-on-v6 { none; };
empty-zones-enable yes;
allow-query { clients; };
allow-recursion { clients; };
allow-transfer { none; };
dnssec-enable yes;
dnssec-validation yes;
};
include "/etc/root_trusted_key";
logging {
category lame-servers { null; };
};
...
Personally, I just have the text from your included file directly in
named.conf file itself.
Take a quick peek at http://dnssec.co.za
On 17/05/2016 22:35, t...@it-hluchnik.de wrote:
> Hi all,
>
> I have a problem with DNSSEC and I dont find a solution. Maybe someone can
> help me.
>
> My intention is to run a bind which acts as DNSSEC enabled resolver for my
> internal LAN. This runs on a VirtualBox instance with OpenBSD 5.9. I got a
> precompiled package from OpenBSD, version is 9.10.3-P3.
>
> Configuring my named, I mostly followed a howto from Calomel.org:
>
> https://calomel.org/dns_bind.html
>
> This is my named.conf:
>
> root@bsd59n:/var/named/etc# egrep -v '^ *#|^ *$|^\/\/' named.conf
> acl clients {
> 127.0.0.0/8;
> 192.168.21.0/24;
> ::1;
> };
> options {
> version ""; // remove this to allow version queries
> listen-on{ 127.0.0.1; 192.168.21.101; };
> listen-on-v6 { none; };
> empty-zones-enable yes;
> allow-query { clients; };
> allow-recursion { clients; };
> allow-transfer { none; };
> include "/etc/root_trusted_key";
> dnssec-enable yes;
> dnssec-validation yes;
> };
> logging {
> category lame-servers { null; };
> };
> zone "." {
> type hint;
> file "etc/root.hint";
> };
> zone "localhost" {
> type master;
> file "standard/localhost";
> allow-transfer { localhost; };
> };
> zone "127.in-addr.arpa" {
> type master;
> file "standard/loopback";
> allow-transfer { localhost; };
> };
>
>
> As my named is running in a chroot jail, /etc/root_trusted_key is
> /var/named/etc/root_trusted_key in reality.
>
> root@bsd59n:/var/named/etc# root_trusted_key
> managed-keys {
>"." initial-key 257 3 8
> "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
> FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
> bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
> X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
> W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
> Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ";
> };
>
> root_trusted_key was generated as Calomel howto describes.
>
> Now, when I try to start named with that config, I get a courious error
> message:
>
>
> root@bsd59n:/var/named/etc# /usr/local/sbin/named -t /var/named -u _bind -U 4
> -g
> 17-May-2016 21:53:14.644 starting BIND 9.10.3-P3 -t /var/named
> -u _bind -U 4 -g
> 17-May-2016 21:53:14.644 built with '--enable-shared' '--enable-filter-'
> '--enable-threads' '--with-libt
> ool' '--without-readline' '--with-python=/usr/local/bin/python2.7'
> '--prefix=/usr/local' '--sysconfdir=/etc'
> '--mandir=/usr/local/man' '--infodir=/usr/local/info' '--localstatedir=/var'
> '--disable-silent-rules' '--di
> sable-gtk-doc' 'CC=cc' 'CFLAGS=-O2 -pipe'
> 17-May-2016 21:53:14.644
> 17-May-2016 21:53:14.644 BIND 9 is maintained by Internet Systems Consortium,
> 17-May-2016 21:53:14.644 Inc. (ISC), a non-profit 501(c)(3) public-benefit
> 17-May-2016 21:53:14.644 corporation. Support and training for BIND 9 are
> 17-May-2016 21:53:14.644 available at https://www.isc.org/support
> 17-May-2016 21:53:14.644
> 17-May-2016 21:53:14.645 found 2 CPUs, using 2 worker threads
> 17-May-2016 21:53:14.645 using 2 UDP listeners per interface
> 17-May-2016 21:53:14.648 using up to 4096 sockets
> 17-May-2016 21:53:14.681 loading configuration from '/etc/named.conf'
> 17-May-2016 21:53:14.683 /etc/root_trusted_key:1: unknown option
> 'managed-keys'
> 17-May-2016 21:53:14.686 loading configuration: failure
> 17-May-2016 21:53:14.686 exiting (due to fatal error)
>
>
> But named documentation and "man named.conf" both say that managed-keys were
> a valid option.
>
> So what's wrong here? Thanks in advance for any help.
>
> Thomas Hluchnik
>
>
>
> ___
> 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
>
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@posix.co.za Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA:
BIND 9.10.4 may have a fatal crash defect.
We are seeing occasional crashes after updating to 9.10.4 on FreeBSD 10.1. May 17 09:46:07 smtp1 named[74136]: general: critical: rbt.c:2576: INSIST(delete)->is_root == 1) ? isc_boolean_true : isc_boolean_false) && *rootp == delete) || (! (((delete)->is_root == 1) ? isc_boolean_true : isc_boolean_false) && (delete)->parent))->left) == delete || delete)->parent))->right) == delete))) failed, back trace May 17 09:46:07 smtp1 named[74136]: general: critical: #0 0x41899d in ?? May 17 09:46:07 smtp1 named[74136]: general: critical: #1 0x5bde7a in ?? May 17 09:46:07 smtp1 named[74136]: general: critical: #2 0x4bcefd in ?? May 17 09:46:07 smtp1 named[74136]: general: critical: #3 0x4c8951 in ?? May 17 09:46:07 smtp1 named[74136]: general: critical: #4 0x4c7fab in ?? May 17 09:46:07 smtp1 named[74136]: general: critical: #5 0x4c834b in ?? May 17 09:46:07 smtp1 named[74136]: general: critical: #6 0x5dd918 in ?? May 17 09:46:07 smtp1 named[74136]: general: critical: #7 0x80186d4f5 in ?? May 17 09:46:07 smtp1 named[74136]: general: critical: #8 0x0 in ?? May 17 09:46:07 smtp1 named[74136]: general: critical: exiting (due to assertion failure) Would love to assist in troubleshooting in any way we might be able to. Benjamin ___ 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.10.4 may have a fatal crash defect.
Known issue triggering a number of insist failures in rbt.c. Please roll back to 9.10.3-P4 while we prepare a new release. In message <573b903f.9000...@electricembers.coop>, Benjamin Connelly writes: > We are seeing occasional crashes after updating to 9.10.4 on FreeBSD 10.1. > > > May 17 09:46:07 smtp1 named[74136]: general: critical: rbt.c:2576: > INSIST(delete)->is_root == 1) ? isc_boolean_true : > isc_boolean_false) && *rootp == delete) || (! (((delete)->is_root == 1) > ? isc_boolean_true : isc_boolean_false) && (delete)->parent))->left) > == delete || delete)->parent))->right) == delete))) failed, back trace > May 17 09:46:07 smtp1 named[74136]: general: critical: #0 0x41899d in ?? > May 17 09:46:07 smtp1 named[74136]: general: critical: #1 0x5bde7a in ?? > May 17 09:46:07 smtp1 named[74136]: general: critical: #2 0x4bcefd in ?? > May 17 09:46:07 smtp1 named[74136]: general: critical: #3 0x4c8951 in ?? > May 17 09:46:07 smtp1 named[74136]: general: critical: #4 0x4c7fab in ?? > May 17 09:46:07 smtp1 named[74136]: general: critical: #5 0x4c834b in ?? > May 17 09:46:07 smtp1 named[74136]: general: critical: #6 0x5dd918 in ?? > May 17 09:46:07 smtp1 named[74136]: general: critical: #7 0x80186d4f5 in ?? > May 17 09:46:07 smtp1 named[74136]: general: critical: #8 0x0 in ?? > May 17 09:46:07 smtp1 named[74136]: general: critical: exiting (due to > assertion failure) > > > Would love to assist in troubleshooting in any way we might be able to. > > Benjamin > ___ > 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 -- 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.10.4 may have a fatal crash defect.
On Wed, May 18, 2016 at 07:45:41AM +1000, Mark Andrews wrote: > Known issue triggering a number of insist failures in rbt.c. > Please roll back to 9.10.3-P4 while we prepare a new release. Note that the probable fix is already in our public git repository. https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=patch;h=04a6d1de64b2b600f1c3a67b82abc32392048692 We're testing it for a few more days before we publish, just to make sure there isn't another error we haven't spotted yet, but this seems almost certain to be it. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
