Nsupdate -l not using session.key
While testing bind 9.7.1 features including automated signing and update-policy local. I encountered some strange behaviour using nsupdate -l. When using nsupdate -l I was not able to update the zone in question and the following error was generated: update-security: error: client 127.0.0.1#9292: view internal: update 'star/IN' denied However: nsupdate -k var/run/named/session.key server 127.0.0.1 Worked fine. Note that the session.key is at the default location. Reading the 97ARM it doesn't appear that I need to specify the location of this file, since its created automatically where I and more importantly nsupdate expect it to be. Any suggestions? -- Kal Feher ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nsupdate -l not using session.key
On 6/30/2010 11:13 AM, Kalman Feher wrote: While testing bind 9.7.1 features including automated signing and update-policy local. I encountered some strange behaviour using nsupdate -l. When using nsupdate -l I was not able to update the zone in question and the following error was generated: update-security: error: client 127.0.0.1#9292: view internal: update 'star/IN' denied Any suggestions? Send your named.conf AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Nsupdate -l not using session.key
On 30/06/10 5:25 PM, Alan Clegg acl...@isc.org wrote:
On 6/30/2010 11:13 AM, Kalman Feher wrote:
While testing bind 9.7.1 features including automated signing and
update-policy local. I encountered some strange behaviour using nsupdate -l.
When using nsupdate -l I was not able to update the zone in question and the
following error was generated:
update-security: error: client 127.0.0.1#9292: view internal: update
'star/IN' denied
Any suggestions?
Send your named.conf
Named.conf:
acl xfer {
none;
};
acl trusted {
127.0.0.0/8;
::1/128;
10.115.160.0/22;
};
options {
directory /var/bind;
pid-file /var/run/named/named.pid;
bindkeys-file /etc/bind/bind.keys;
listen-on-v6 { none; };
listen-on port 53 { any; };
allow-query {
trusted;
};
allow-query-cache {
trusted;
};
allow-transfer {
xfer;
};
dnssec-enable yes;
};
logging {
channel default_log {
file /var/log/named/named.log versions 5 size 50M;
print-time yes;
print-severity yes;
print-category yes;
};
channel query_log {
file /var/log/named/query.log versions 5 size 100M;
print-time yes;
print-severity yes;
print-category yes;
};
channel dnssec_log {
file /var/log/named/dnssec.log versions 5 size 100M;
print-time yes;
print-severity yes;
print-category yes;
};
channel resolver_log {
file /var/log/named/resolver.log versions 5 size 50M;
print-time yes;
print-severity yes;
print-category yes;
};
category default { default_log; };
category general { default_log; default_syslog; };
category queries { query_log; };
category dnssec { dnssec_log; };
category resolver { resolver_log; };
};
include /etc/bind/rndc.key;
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1/32; ::1/128; } keys {
rndc-key; };
};
view internal in {
match-clients { trusted; };
recursion yes;
additional-from-auth yes;
additional-from-cache yes;
zone . in {
type hint;
file /var/bind/root.cache;
};
zone localhost IN {
type master;
file pri/localhost.zone;
allow-update { none; };
notify no;
allow-query { any; };
allow-transfer { none; };
};
zone 127.in-addr.arpa IN {
type master;
file pri/127.zone;
allow-update { none; };
notify no;
allow-query { any; };
allow-transfer { none; };
};
zone star IN {
type master;
auto-dnssec maintain;
update-policy local;
dnssec-secure-to-insecure no;
file pri/star/star.zone.signed;
key-directory pri/star;
notify no;
allow-query { any; };
allow-transfer { none; };
};
zone COM { type delegation-only; };
zone NET { type delegation-only; };
};
view public in {
match-clients { any; };
recursion no;
additional-from-auth no;
additional-from-cache no;
zone . in {
type hint;
file /var/bind/root.cache;
};
};
view chaos chaos {
match-clients { any; };
allow-query { none; };
zone . {
type hint;
file /dev/null; };
};
AlanC
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Kal Feher
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
negative caching and TTL
Hi, I am hoping to learn more about how BIND v 9.7.0 implements negative caching of delegated subdomains. I've tested and found that BIND observes a different TTL for name errors than I would expect it to abide by, but that could be my lack of understanding of what TTL a DNS server is supposed to abide by in this situation. (I've changed the actual domain names as they are only used in our internal network and you can't get to it from the internet anyway.) We have abc.com that BIND 9.7.0 is authoritative for. And in named.hosts of (host: bind1.abc.com), we have: xyz 30 IN NS dns1.abc.com. xyz 30 IN NS dns2.abc.com. On bind1.abc.com, if you query for a host that doesn't exist, this is dig's output: dig nohost.xyz.abc.com @bind1.abc.com ; DiG 9.3.5-P1 nohost.xyz.abc.com @bind1.abc.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 1298 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;nohost.xyz.abc.com.IN A ;; AUTHORITY SECTION: xyz.abc.com. 10800 IN SOA localhost. admin.abc.com. 1 60 3600 604800 3600 From my tests, Bind is observing the '10800' TTL for nohost.xyz.abc.com, not '3600' that's in the SOA minimum field. The question is why is the TTL of the SOA record used for caching negative answers, not the TTL in the SOA minimum field? Reading http://www.dns.net/dnsrd/rfc/rfc2308.html, it says: Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. This is required so that the response may be cached. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. And that doesn't seem clear to me, as TTL of the negative response is cached from BOTH the minimum field and the TTL of the SOA record? But in Bind, it seems like it's taking the TTL of the SOA. If anyone has an explanation to this, please chime in. thanks. AJ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind-9.7.1 multi thread question (FreeBSD)
Hello
I compiled Bind971 on FreeBSD 8 (amd64).
!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-520092929 1073786111 9 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:;
margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:0in;
line-height:115%;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:Calibri,sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:Arial;
mso-bidi-theme-font:minor-bidi;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-family:Calibri,sans-serif;
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:Arial;
mso-bidi-theme-font:minor-bidi;}
.MsoPapDefault
{mso-style-type:export-only;
margin-bottom:10.0pt;
line-height:115%;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.WordSection1
{page:WordSection1;}
--
./configure --prefix=/opt/
--enable-threads --sysconfdir=/opt/config --localstatedir=/opt/
--sbindir=/opt/named --datarootdir=/opt/ --enable-shared=no
--with-openssl
everything is ok and it works. but when i get top command,,freebsd returns
many named processess which are run,,is it ok?(on my previous installed
bind9.6 on solaris it didnt show these in prstat -a)
PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND
396 root7 490 3207M 2575M kqread 3 725:01 19.97% named
71422 root1 440 28652K 8768K select 1 0:46 0.00% snmpd
882 root1 440 5864K 1512K select 0 0:00 0.00% syslogd
1117 root1 440 6920K 1588K nanslp 2 0:00 0.00% cron
543 root7 440 20640K 11844K kqread 0 0:00 0.00% named
637 root7 440 20640K 11888K kqread 2 0:00 0.00% named
531 root7 440 20640K 11844K kqread 0 0:00 0.00% named
725 root7 440 20640K 11888K kqread 2 0:00 0.00% named
602 root7 440 20640K 11888K kqread 2 0:00 0.00% named
679 root7 440 20640K 11844K kqread 2 0:00 0.00% named
597 root7 440 20640K 11888K kqread 0 0:00 0.00% named
695 root7 440 20640K 11844K kqread 2 0:00 0.00% named
684 root7 440 20640K 11888K kqread 1 0:00 0.00% named
613 root7 440 19616K 11800K kqread 1 0:00 0.00% named
555 root7 440 20640K 11844K kqread 1 0:00 0.00% named
625 root7 440 20640K 11888K kqread 0 0:00 0.00% named
846 root7 440 20640K 11888K kqread 1 0:00 0.00% named
707 root7 440 20640K 11888K kqread 3 0:00 0.00% named
1128 root7 440 20640K 11856K kqread 0 0:00 0.00% named
1360 root7 440 20640K 11924K kqread 1 0:00 0.00% named
70665 root7 440 20640K 11924K kqread 0 0:00 0.00% named
1376 operator7 440 20640K 11904K kqread 0 0:00 0.00% named
1337 operator7 440 20640K 11948K kqread 0 0:00 0.00% named
1252 operator7 440 20640K 11948K kqread 3 0:00 0.00% named
1276 operator7 440 20640K 11904K kqread 3 0:00 0.00% named
1232 operator7 440 20640K 11948K kqread 1 0:00 0.00% named
1298 root7 440 20640K 11880K kqread 0 0:00 0.00% named
1319 operator7 440 20640K 11948K kqread 3 0:00 0.00% named
71374 operator7 440 19616K 11856K kqread 1 0:00 0.00% named
70559 operator7 440 20640K 11904K kqread 3 0:00 0.00% named
70630 root7 440 20640K 11880K kqread 0 0:00 0.00% named
70443 operator7 440 20640K 11948K kqread 2 0:00 0.00% named
70612 root7 440 20640K 11924K kqread 3 0:00 0.00% named
70590 operator7 440 20640K 11904K kqread 1 0:00 0.00% named
70464 operator7 440 20640K 11904K kqread 0 0:00 0.00% named
71884 root1 440 10352K 3800K CPU00 0:00 0.00% top
1304 root7 440 20640K 11876K kqread 1 0:00 0.00% named
70618 root7 440 20640K
Re: Bind-9.7.1 multi thread question (FreeBSD)
On Wed, 30 Jun 2010, Bind wrote: Hello I compiled Bind971 on FreeBSD 8 (amd64). FYI, you may get better results by using /usr/ports/dns/bind97. !-- /* Font Definitions */ Not sure why you included this. ./configure --prefix=/opt/ --enable-threads --sysconfdir=/opt/config --localstatedir=/opt/ --sbindir=/opt/named --datarootdir=/opt/ --enable-shared=no --with-openssl Those basically look fine, non-standard paths for FreeBSD, but that's ok. everything is ok and it works. but when i get top command,, What top command line are you using exactly, and is there anything in the $TOP environment variable? freebsd returns many named processess which are run,,is it ok? No. You appear to be running numerous named processes. Try 'killall named' and then start the named binary directly on the command line (no scripts, or other tools) and then repeat your top command. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: negative caching and TTL
In message aanlktilsbfrzbbauc54wdlqhmkcwlicvzjrdqxcck...@mail.gmail.com, aldu s jung writes: Hi, I am hoping to learn more about how BIND v 9.7.0 implements negative caching of delegated subdomains. I've tested and found that BIND observes a different TTL for name errors than I would expect it to abide by, but that could be my lack of understanding of what TTL a DNS server is supposed to abide by in this situation. (I've changed the actual domain names as they are only used in our internal network and you can't get to it from the internet anyway.) We have abc.com that BIND 9.7.0 is authoritative for. And in named.hosts of (host: bind1.abc.com), we have: xyz 30 IN NS dns1.abc.com. xyz 30 IN NS dns2.abc.com. On bind1.abc.com, if you query for a host that doesn't exist, this is dig's output: dig nohost.xyz.abc.com @bind1.abc.com ; DiG 9.3.5-P1 nohost.xyz.abc.com @bind1.abc.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 1298 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;nohost.xyz.abc.com.IN A ;; AUTHORITY SECTION: xyz.abc.com. 10800 IN SOA localhost. admin.abc.com. 1 60 3600 604800 3600 From my tests, Bind is observing the '10800' TTL for nohost.xyz.abc.com, not '3600' that's in the SOA minimum field. The question is why is the TTL of the SOA record used for caching negative answers, not the TTL in the SOA minimum field? Reading http://www.dns.net/dnsrd/rfc/rfc2308.html, it says: Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. This is required so that the response may be cached. The TTL of this record is set from the minimum of the MINIMUM field of the SOA record and the TTL of the SOA itself, and indicates how long a resolver may cache the negative answer. And that doesn't seem clear to me, as TTL of the negative response is cached from BOTH the minimum field and the TTL of the SOA record? But in Bind, it seems like it's taking the TTL of the SOA. If anyone has an explanation to this, please chime in. thanks. AJ Named honoured the TTL of the negative response it got from the child zone within the bound set by max-ncache-ttl. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind dlz(mysql)
SOA Record query : 01-Jul-2010 12:00:09.121 dns_rdata_fromtext: buffer-0xbff9b414:1: near '20100701000': out of range 01-Jul-2010 12:00:09.121 dns_sdlz_putrr returned error. Error code was: out of range What is the scope of the serial field values? and data fields(table:dns_records) cannot be empty,which is the value of primary name server= in a SOA query? -- ShanyiWan 2010-07-01 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind dlz(mysql)
In message 201007011210381811...@114.com.cn, ShanyiWan writes: SOA Record query : 01-Jul-2010 12:00:09.121 dns_rdata_fromtext: buffer-0xbff9b414:1: near '20100 701000': out of range 01-Jul-2010 12:00:09.121 dns_sdlz_putrr returned error. Error code was: out o f range What is the scope of the serial field values? [0..4294967295] (0, 2^32-1) If you want to encode the date it should be MMDDVV (2V's) not MMDDVVV (3V's). MMDDVV is good until the start of 4295. and data fields(table:dns_records) cannot be empty,which is the value of pr imary name server= in a SOA query? Normally it is the name of the machine from which the other nameservers transfer the zone contents. As you are using DLZ the nameserver to which you want update requests sent or use . as a placeholder. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
