Re: ISC BIND 9.8.0 is now available
In addition to my pvt email Evan The dev link page still shows 9.7.3 as current production, no 9.8.0, but going to all downloads shows 9.8.0 as current production, and as things happen in three's ... bind-9.8.0.tar.gz clicking on this yields a file called bind-980targzno periods, looks like some script has collapsed asc sha1 sha256 sha512 works for me : /opt/csw/bin/wget http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz $ /opt/schily/bin/mdigest -a sha256 bind-9.8.0.tar.gz e44183f5a4ab7d3deb3c08171c4821c391d6b10ed8d4bc6485a1fc3ba6490c06 bind-9.8.0.tar.gz $ /opt/csw/bin/wget http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz.sha512.asc --2011-03-03 09:42:06-- http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz.sha512.asc Resolving ftp.isc.org... 204.152.184.110 Connecting to ftp.isc.org|204.152.184.110|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 481 [text/plain] Saving to: `bind-9.8.0.tar.gz.sha512.asc' 0K 100% 9.42M=0s 2011-03-03 09:42:06 (9.42 MB/s) - `bind-9.8.0.tar.gz.sha512.asc' saved [481/481] $ /opt/csw/bin/wget http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz.sha256.asc --2011-03-03 09:42:15-- http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz.sha256.asc Resolving ftp.isc.org... 204.152.184.110 Connecting to ftp.isc.org|204.152.184.110|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 481 [text/plain] Saving to: `bind-9.8.0.tar.gz.sha256.asc' 0K 100% 8.51M=0s 2011-03-03 09:42:15 (8.51 MB/s) - `bind-9.8.0.tar.gz.sha256.asc' saved [481/481] $ /opt/csw/bin/wget http://www.isc.org/files/pgpkey2009.txt --2011-03-03 09:45:13-- http://www.isc.org/files/pgpkey2009.txt Resolving www.isc.org... 149.20.64.42 Connecting to www.isc.org|149.20.64.42|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2849 (2.8K) [text/plain] Saving to: `pgpkey2009.txt' 0K 100% 51.3M=0s 2011-03-03 09:45:14 (51.3 MB/s) - `pgpkey2009.txt' saved [2849/2849] $ /opt/csw/bin/gpg --import pgpkey2009.txt gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: key 0B7BAE00: public key Internet Systems Consortium, Inc. (Signing key, 2009) pgpkey2...@isc.org imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 2 signed: 2 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: depth: 1 valid: 2 signed: 2 trust: 2-, 0q, 0n, 0m, 0f, 0u $ /opt/csw/bin/gpg --verify bind-9.8.0.tar.gz.sha256.asc bind-9.8.0.tar.gz gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Mon Feb 28 15:57:39 2011 GMT using RSA key ID 0B7BAE00 gpg: Good signature from Internet Systems Consortium, Inc. (Signing key, 2009) pgpkey2...@isc.org gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: FA76 7A86 A371 E359 22F6 A5C8 D811 B53F 0B7B AE00 $ /opt/csw/bin/gpg --verify bind-9.8.0.tar.gz.sha512.asc bind-9.8.0.tar.gz gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Mon Feb 28 15:57:38 2011 GMT using RSA key ID 0B7BAE00 gpg: Good signature from Internet Systems Consortium, Inc. (Signing key, 2009) pgpkey2...@isc.org gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: FA76 7A86 A371 E359 22F6 A5C8 D811 B53F 0B7B AE00 $ -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Having trouble with logging syntax
I got my logging setup but named-checkconf is spitting out an error.
$named-checkconf /home/nate/named.conf.local
/home/nate/named.conf.local:11: missing ';' before '3'
/home/nate/named.conf.local:11: unknown option '3'
I'm pretty sure we don't put an ; after version. I can't see anything
wrong with my config. All my ; look to be in place. I'm using Ubuntu
10.04. This is strictly a resolver server on my personal PC at home.
My logging setup.
logging {
channel query.log {
file /var/log/query.log version; 3 size 5m;
severity warning;
print-time yes;
print-severity yes;
print-category yes;
};
category lame-servers { null; };
category default { syslog; };
};
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Having trouble with logging syntax
Change:
file /var/log/query.log version; 3 size 5m;
to:
file /var/log/query.log versions 3 size 5m;
-Original Message-
From: bind-users-bounces+tsnyder=rim@lists.isc.org
[mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of Nate
Homier
Sent: Thursday, March 03, 2011 3:30 PM
To: bind-users@lists.isc.org
Subject: Having trouble with logging syntax
I got my logging setup but named-checkconf is spitting out an error.
$named-checkconf /home/nate/named.conf.local
/home/nate/named.conf.local:11: missing ';' before '3'
/home/nate/named.conf.local:11: unknown option '3'
I'm pretty sure we don't put an ; after version. I can't see anything
wrong with my config. All my ; look to be in place. I'm using Ubuntu
10.04. This is strictly a resolver server on my personal PC at home.
My logging setup.
logging {
channel query.log {
file /var/log/query.log version; 3 size 5m;
severity warning;
print-time yes;
print-severity yes;
print-category yes;
};
category lame-servers { null; };
category default { syslog; };
};
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Having trouble with logging syntax
On Mar 3, 2011, at 3:30 PM, Nate Homier wrote:
I got my logging setup but named-checkconf is spitting out an error.
$named-checkconf /home/nate/named.conf.local
/home/nate/named.conf.local:11: missing ';' before '3'
/home/nate/named.conf.local:11: unknown option '3'
I'm pretty sure we don't put an ; after version.
Erm, but there is one in your example -- just wanted to make sure you
knew...
Anyway, I think it is 'versions' (plural), not 'version' (singular)
W
I can't see anything
wrong with my config. All my ; look to be in place. I'm using Ubuntu
10.04. This is strictly a resolver server on my personal PC at home.
My logging setup.
logging {
channel query.log {
file /var/log/query.log version; 3 size 5m;
severity warning;
print-time yes;
print-severity yes;
print-category yes;
};
category lame-servers { null; };
category default { syslog; };
};
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Hope is not a strategy.
-- Ben Treynor, Google
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Having trouble with logging syntax
Dnia 2011-03-03 13:30 Nate Homier napisał(a):
I got my logging setup but named-checkconf is spitting out an error.
$named-checkconf /home/nate/named.conf.local
/home/nate/named.conf.local:11: missing ';' before '3'
/home/nate/named.conf.local:11: unknown option '3'
I'm pretty sure we don't put an ; after version. I can't see anything
wrong with my config. All my ; look to be in place. I'm using Ubuntu
10.04. This is strictly a resolver server on my personal PC at home.
My logging setup.
logging {
channel query.log {
file /var/log/query.log version; 3 size 5m;
that would by file /var/log/query.log version 3 size 5m;
You want 3 versions, so why separate keyword from its parameter?
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Having trouble with logging syntax
On Thu, 2011-03-03 at 21:56 +0100, Torinthiel wrote:
Dnia 2011-03-03 13:30 Nate Homier napisał(a):
I got my logging setup but named-checkconf is spitting out an error.
$named-checkconf /home/nate/named.conf.local
/home/nate/named.conf.local:11: missing ';' before '3'
/home/nate/named.conf.local:11: unknown option '3'
I'm pretty sure we don't put an ; after version. I can't see anything
wrong with my config. All my ; look to be in place. I'm using Ubuntu
10.04. This is strictly a resolver server on my personal PC at home.
My logging setup.
logging {
channel query.log {
file /var/log/query.log version; 3 size 5m;
that would by file /var/log/query.log version 3 size 5m;
You want 3 versions, so why separate keyword from its parameter?
Torinthiel
That was pointed out to me. I put the ; in by accident. And I missed
putting an s at the end of version. Thanks for the reply.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC BIND 9.8.0 is now available
It should work too, it was fixed within in a few minutes :) On Thu, 2011-03-03 at 04:47 -0500, Dennis Clarke wrote: In addition to my pvt email Evan The dev link page still shows 9.7.3 as current production, no 9.8.0, but going to all downloads shows 9.8.0 as current production, and as things happen in three's ... bind-9.8.0.tar.gz clicking on this yields a file called bind-980targzno periods, looks like some script has collapsed asc sha1 sha256 sha512 works for me : /opt/csw/bin/wget http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz $ /opt/schily/bin/mdigest -a sha256 bind-9.8.0.tar.gz e44183f5a4ab7d3deb3c08171c4821c391d6b10ed8d4bc6485a1fc3ba6490c06 bind-9.8.0.tar.gz $ /opt/csw/bin/wget http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz.sha512.asc --2011-03-03 09:42:06-- http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz.sha512.asc Resolving ftp.isc.org... 204.152.184.110 Connecting to ftp.isc.org|204.152.184.110|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 481 [text/plain] Saving to: `bind-9.8.0.tar.gz.sha512.asc' 0K 100% 9.42M=0s 2011-03-03 09:42:06 (9.42 MB/s) - `bind-9.8.0.tar.gz.sha512.asc' saved [481/481] $ /opt/csw/bin/wget http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz.sha256.asc --2011-03-03 09:42:15-- http://ftp.isc.org/isc/bind9/9.8.0/bind-9.8.0.tar.gz.sha256.asc Resolving ftp.isc.org... 204.152.184.110 Connecting to ftp.isc.org|204.152.184.110|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 481 [text/plain] Saving to: `bind-9.8.0.tar.gz.sha256.asc' 0K 100% 8.51M=0s 2011-03-03 09:42:15 (8.51 MB/s) - `bind-9.8.0.tar.gz.sha256.asc' saved [481/481] $ /opt/csw/bin/wget http://www.isc.org/files/pgpkey2009.txt --2011-03-03 09:45:13-- http://www.isc.org/files/pgpkey2009.txt Resolving www.isc.org... 149.20.64.42 Connecting to www.isc.org|149.20.64.42|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2849 (2.8K) [text/plain] Saving to: `pgpkey2009.txt' 0K 100% 51.3M=0s 2011-03-03 09:45:14 (51.3 MB/s) - `pgpkey2009.txt' saved [2849/2849] $ /opt/csw/bin/gpg --import pgpkey2009.txt gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: key 0B7BAE00: public key Internet Systems Consortium, Inc. (Signing key, 2009) pgpkey2...@isc.org imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 2 signed: 2 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: depth: 1 valid: 2 signed: 2 trust: 2-, 0q, 0n, 0m, 0f, 0u $ /opt/csw/bin/gpg --verify bind-9.8.0.tar.gz.sha256.asc bind-9.8.0.tar.gz gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Mon Feb 28 15:57:39 2011 GMT using RSA key ID 0B7BAE00 gpg: Good signature from Internet Systems Consortium, Inc. (Signing key, 2009) pgpkey2...@isc.org gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: FA76 7A86 A371 E359 22F6 A5C8 D811 B53F 0B7B AE00 $ /opt/csw/bin/gpg --verify bind-9.8.0.tar.gz.sha512.asc bind-9.8.0.tar.gz gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/faq.html for more information gpg: Signature made Mon Feb 28 15:57:38 2011 GMT using RSA key ID 0B7BAE00 gpg: Good signature from Internet Systems Consortium, Inc. (Signing key, 2009) pgpkey2...@isc.org gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: FA76 7A86 A371 E359 22F6 A5C8 D811 B53F 0B7B AE00 $ signature.asc Description: This is a digitally signed message part ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND servfail from caching server
When doing a recursive query for MX supernet.com against a caching BIND server, the BIND server responds back with the answer. The TTL is 300. After the TTL expires the following recursive query for the same record returns a SERVFAIL from the caching server. If I do a +trace on the same query to the same caching server for the same data it is able to respond with the answer yet a standard recursive query still gives a SERVFAIL. Queries for other domains are working fine on this caching server. Other 3rd party DNS caching servers are responding fine for the same record above even after the TTL expires, tried @8.8.8.8 and @208.67.220.220 If if flush the cache on the caching server it successfully returns the answer to the query but only for the up the TTL's life then goes back to SERVFAIL again. (tried doing a full stop-and-start of named as well). This particular server is running BIND 9.7.0-P2 but this exact same behavior is also happening on a server running 9.5.1-P2.1 as well. So I noticed when doing a trace that the NS servers are different between the gtld and the actual authoritative servers. snip com.172800 IN NS l.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. ;; Received 502 bytes from 192.36.148.17#53(i.root-servers.net) in 2987 ms supernet.com. 172800 IN NS ns2.earthlink.net. supernet.com. 172800 IN NS ns3.earthlink.net. ;; Received 111 bytes from 192.54.112.30#53(h.gtld-servers.net) in 119 ms supernet.com. 300 IN MX 5 onemain-mx.earthlink.net. supernet.com. 3600IN NS dns1.earthlink.net. supernet.com. 3600IN NS dns2.earthlink.net. ;; Received 172 bytes from 207.217.120.43#53(ns3.earthlink.net) in 54 ms Is this just a bug that upgrading BIND will fix or is there something else going on here? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND servfail from caching server
Forgot to additionally add that the only thing that showed up in the logs was the query log entry, nothing else pertaining the below query. I also checked with tcpdump on the caching server that it was not sending any queries towards the Earthlink IP addresses which makes sense given that the SERVFAIL response comes back in 2 ms according to dig. On Thu, 2011-03-03 at 16:29 -0600, Justin Krejci wrote: When doing a recursive query for MX supernet.com against a caching BIND server, the BIND server responds back with the answer. The TTL is 300. After the TTL expires the following recursive query for the same record returns a SERVFAIL from the caching server. If I do a +trace on the same query to the same caching server for the same data it is able to respond with the answer yet a standard recursive query still gives a SERVFAIL. Queries for other domains are working fine on this caching server. Other 3rd party DNS caching servers are responding fine for the same record above even after the TTL expires, tried @8.8.8.8 and @208.67.220.220 If if flush the cache on the caching server it successfully returns the answer to the query but only for the up the TTL's life then goes back to SERVFAIL again. (tried doing a full stop-and-start of named as well). This particular server is running BIND 9.7.0-P2 but this exact same behavior is also happening on a server running 9.5.1-P2.1 as well. So I noticed when doing a trace that the NS servers are different between the gtld and the actual authoritative servers. snip com.172800 IN NS l.gtld-servers.net. com.172800 IN NS e.gtld-servers.net. ;; Received 502 bytes from 192.36.148.17#53(i.root-servers.net) in 2987 ms supernet.com. 172800 IN NS ns2.earthlink.net. supernet.com. 172800 IN NS ns3.earthlink.net. ;; Received 111 bytes from 192.54.112.30#53(h.gtld-servers.net) in 119 ms supernet.com. 300 IN MX 5 onemain-mx.earthlink.net. supernet.com. 3600IN NS dns1.earthlink.net. supernet.com. 3600IN NS dns2.earthlink.net. ;; Received 172 bytes from 207.217.120.43#53(ns3.earthlink.net) in 54 ms Is this just a bug that upgrading BIND will fix or is there something else going on here? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND servfail from caching server
It's because the NS RRSet returned by the authoritative name servers lists
servers that are not authoritative. Classic DNS mistake.
The com zone says that the authoritative servers for supernet.com are
ns{2,3}.earthlink.net (delegation).
But supernet.com as hosted on ns{2,3}.earthlink.net says that
dns{1,2}.earthlink.net are the authoritative servers. This latter set of
servers is not actually authoritative for the zone.
For the first query, the resolver has not yet talked to the authoritative
servers, so its only information is the delegation NS record set from com. The
answer to that query, however, contains the authoritative NS record set, which
is considered more credible and therefore replaces the delegation record set in
the resolver's cache. Subsequent queries into the zone go to the bad servers,
get lame responses, and fail.
Unless you own supernet.com, this problem is not your fault and not for you to
fix. You can work around it with conditional forwarding, or a zone of type
static-stub if you're using BIND 9.8 already, but that's strictly a workaround
and subject to breakage if the zone is moved.
Chris Buxton
BlueCat Networks
On Mar 3, 2011, at 2:29 PM, Justin Krejci wrote:
When doing a recursive query for MX supernet.com against a caching BIND
server, the BIND server responds back with the answer. The TTL is 300.
After the TTL expires the following recursive query for the same record
returns a SERVFAIL from the caching server.
If I do a +trace on the same query to the same caching server for the
same data it is able to respond with the answer yet a standard recursive
query still gives a SERVFAIL.
Queries for other domains are working fine on this caching server. Other
3rd party DNS caching servers are responding fine for the same record
above even after the TTL expires, tried @8.8.8.8 and @208.67.220.220
If if flush the cache on the caching server it successfully returns the
answer to the query but only for the up the TTL's life then goes back to
SERVFAIL again. (tried doing a full stop-and-start of named as well).
This particular server is running BIND 9.7.0-P2 but this exact same
behavior is also happening on a server running 9.5.1-P2.1 as well.
So I noticed when doing a trace that the NS servers are different
between the gtld and the actual authoritative servers.
snip
com.172800 IN NS l.gtld-servers.net.
com.172800 IN NS e.gtld-servers.net.
;; Received 502 bytes from 192.36.148.17#53(i.root-servers.net) in 2987
ms
supernet.com. 172800 IN NS ns2.earthlink.net.
supernet.com. 172800 IN NS ns3.earthlink.net.
;; Received 111 bytes from 192.54.112.30#53(h.gtld-servers.net) in 119
ms
supernet.com. 300 IN MX 5
onemain-mx.earthlink.net.
supernet.com. 3600IN NS dns1.earthlink.net.
supernet.com. 3600IN NS dns2.earthlink.net.
;; Received 172 bytes from 207.217.120.43#53(ns3.earthlink.net) in 54 ms
Is this just a bug that upgrading BIND will fix or is there something
else going on here?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
