Re: nsupdate.exe and IPv6
Chris Hills wrote: Hi It seems nsupdate.exe in 9.6.1-P1 does not properly locate IPv6 nameservers. C:\Temp\bind-9.6.1-P1dig +short ns-v6-1.chaz6.com. in 2001:16d8:dd22:38::2 2001:16d8:ee0f:38::2 C:\Temp\bind-9.6.1-P1nsupdate server 2001:16d8:dd22:38::2 update add localhost.dyn.ipv6.chaz6.com. 7200 IN :: quit C:\Temp\bind-9.6.1-P1nsupdate update delete localhost.dyn.ipv6.chaz6.com. couldn't get address for 'ns-v6-1.chaz6.com': not found The same works fine from Linux:- $ rpmquery --whatprovides `which nsupdate` bind-utils-9.6.1P1-4.1.i586 $ nsupdate update add localhost.dyn.ipv6.chaz6.com. 7200 IN ::1 update delete localhost.dyn.ipv6.chaz6.com. quit Regards, Chris P.S. Is there a proper bug reporting address? I could not find it on the website. Chris - thanks for this - we've picked it up and made a bug report ourselves. But for future reference, our BIND mailing addresses are summarised here: https://www.isc.org/software/bind/news Cathy ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Split view logging?
On Thu, 2009-11-19 at 14:55 -0800, Gregory Hicks wrote:
From: Chris Buxton cbux...@menandmice.com
Date: Tue, 17 Nov 2009 08:16:18 -0800
On Nov 17, 2009, at 7:02 AM, John Horne wrote:
Hello,
Using BIND 9.5.1, is it possible to configure split view logging -
that is, a separate logging channel/category for different views?
I'm trying to separate out the queries of our local clients from
the external ones.
No, not using views. The logging statement, like the options
statement, is a singleton statement type.
You would have to stand up separate instances of named, with separate
configs, to achieve your goal.
Well, not exactly...
I have two views: trusted (hosts on my internal LAN), and external
(hosts external to my LAN). I want queries logged from my internal LAN
to /var/log/named.trusted.{0-9} and all other queries to go to
/var/log/named.external.{0-9}. I've also got some odd sods and trash
going to other log files...
First, create a 'pipe' in the /var/log directory with the name of the
logging file. (You probably want to do this in the named startup
script.) Log absolutely EVERYTHING to the log file.
Wow! Well thanks for that. I can see that your way would work, however I
was hoping for something a little simpler like putting logging stmts
into each view :-) (Perhaps BIND 10?)
Thanks for the reply,
John.
--
John Horne Tel: +44 (0)1752 587287
University of Plymouth, UK Fax: +44 (0)1752 587001
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate.exe and IPv6
On 23/11/09 11:15, Cathy Almond wrote: Chris - thanks for this - we've picked it up and made a bug report ourselves. But for future reference, our BIND mailing addresses are summarised here: https://www.isc.org/software/bind/news Cathy Thanks Cathy! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DIG -6 +TCP
I've got a closed lab testing BIND and I've got an interesting problem with IPv6 queries. Now I have 3 systems all running IPv4 and IPv6. IPv4 queries work fine across all systems. IPv6 UDP queries work fine as well. When I test IPv6 TCP queries I get the following failure: [r...@dig-client ~]# dig -6 a test.domain @bindserver6 +tcp socket.c:4922: 22/Invalid argument dig: isc_socket_connect: unexpected error Can you use other services over IPv6 in the lab? Also, what version of BIND are you using? With 9.6.1-P1 I'm not having any problems with an external query such as: dig -6 @ns.isc.afilias-nst.info isc.org soa +tcp I am using BIND 9.6.1-P1. Ping6 works, and I can run UDP based dig (+notcp) with no issues. IPv6 / TCP based queries fail. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding updates between views
On Nov 22, 2009, at 7:23 PM, Chris Hills wrote:
On 22/11/09 21:01, Chris Buxton wrote:
Change the zone from type forward to type slave, and add
allow-update-forwarding.
zone dyn.example.com. {
type slave;
masters { ::1; };
allow-update-forwarding { local-networks; };
};
Then in the external-in view, change allow-update to:
allow-update { ::1; };
Great, works like a charm... but... the update log only records ::1 as the
source and not the original address. Is it possible to keep that?
The internal-in view should have some log entry of the forwarded update. I'm
not sure what category or severity level that would be, though.
Of course, if you were to start using signed updates (either TSIG or GSS-TSIG),
you would know what key was used.
Chris Buxton
Professional Services
Men Mice
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
SERVFAIL on 9.6.1-P1
Hello BIND users,
We experienced a SERVFAIL on a single domain this morning but were able to
resolve the issue by flushing the servers cache with rndc flush¹.
I gathered some debugs (below) and am hoping someone can shed light on what
might have been causing the failure.
Note: I replaced the real domain with ³{domain removed}² in the debugs.
Before rndc flush:
23-Nov-2009 10:19:59.213 debug 3: client 24.217.29.1#42785: UDP request
23-Nov-2009 10:19:59.213 debug 3: client 24.217.29.1#42785: query
23-Nov-2009 10:19:59.213 debug 3: client 24.217.29.1#42785: replace
23-Nov-2009 10:19:59.213 debug 1: createfetch: {domain removed} A
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'): create
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'): join
23-Nov-2009 10:19:59.214 debug 3: fetch 56b4cb0 (fctx 98757d0({domain
removed}/A)): created
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'): start
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'): try
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'):
cancelqueries
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'):
getaddresses
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'): no
addresses
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'): done
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'):
stopeverything
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'):
cancelqueries
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'):
sendevents
23-Nov-2009 10:19:59.215 debug 1: client 24.217.29.1#42785: query failed
(SERVFAIL) for {domain removed}/IN/A at query.c:4619
23-Nov-2009 10:19:59.215 debug 3: client 24.217.29.1#42785: error
23-Nov-2009 10:19:59.215 debug 3: client 24.217.29.1#42785: send
23-Nov-2009 10:19:59.215 debug 3: client 24.217.29.1#42785: sendto
23-Nov-2009 10:19:59.216 debug 3: client 24.217.29.1#42785: senddone
23-Nov-2009 10:19:59.216 debug 3: client 24.217.29.1#42785: next
23-Nov-2009 10:19:59.216 debug 3: client 24.217.29.1#42785: endrequest
23-Nov-2009 10:19:59.216 debug 2: fetch completed at resolver.c:2998 for
{domain removed}/A in 0.001186: failure/success [domain:{domain
removed},referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,
adberr:2,findfail:0,valfail:0]
23-Nov-2009 10:19:59.216 debug 3: fetch 56b4cb0 (fctx 98757d0({domain
removed}/A)): destroyfetch
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'):
shutdown
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'):
doshutdown
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'):
stopeverything
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'):
cancelqueries
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'): destroy
After rndc flush:
23-Nov-2009 10:20:07.047 debug 3: client 24.217.29.1#43324: UDP request
23-Nov-2009 10:20:07.047 debug 3: client 24.217.29.1#43324: query
23-Nov-2009 10:20:07.047 debug 3: client 24.217.29.1#43324: replace
23-Nov-2009 10:20:07.047 debug 1: createfetch: {domain removed} A
23-Nov-2009 10:20:07.048 debug 3: fctx 9875a30({domain removed}/A'): create
23-Nov-2009 10:20:07.048 debug 3: fctx 9875a30({domain removed}/A'): join
23-Nov-2009 10:20:07.048 debug 3: fetch 9a6d2c8 (fctx 9875a30({domain
removed}/A)): created
23-Nov-2009 10:20:07.084 debug 3: fctx 9875a30({domain removed}/A'): start
23-Nov-2009 10:20:07.084 debug 3: fctx 9875a30({domain removed}/A'): try
23-Nov-2009 10:20:07.085 debug 3: fctx 9875a30({domain removed}/A'):
cancelqueries
23-Nov-2009 10:20:07.085 debug 3: fctx 9875a30({domain removed}/A'):
getaddresses
23-Nov-2009 10:20:07.086 debug 3: fctx 9875a30({domain removed}/A'): query
23-Nov-2009 10:20:07.086 debug 3: resquery 987b310 (fctx 9875a30({domain
removed}/A)): send
23-Nov-2009 10:20:07.087 debug 3: resquery 987b310 (fctx 9875a30({domain
removed}/A)): sent
23-Nov-2009 10:20:07.092 debug 3: resquery 987b310 (fctx 9875a30({domain
removed}/A)): udpconnected
23-Nov-2009 10:20:07.092 debug 3: resquery 987b310 (fctx 9875a30({domain
removed}/A)): senddone
23-Nov-2009 10:20:07.370 debug 3: resquery 987b310 (fctx 9875a30({domain
removed}/A)): response
23-Nov-2009 10:20:07.370 debug 3: fctx 9875a30({domain removed}/A'):
noanswer_response
23-Nov-2009 10:20:07.370 debug 3: fctx 9875a30({domain removed}/A'):
cache_message
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'):
cancelquery
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'):
cancelqueries
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'): try
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'):
cancelqueries
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'):
getaddresses
23-Nov-2009 10:20:07.372 debug 3: fctx 9875a30({domain removed}/A'): query
23-Nov-2009 10:20:07.372 debug 3: resquery 987b310 (fctx 9875a30({domain
Re: DIG -6 +TCP
For all it's worth, using wireshark, I can see IPv6 UDP queries successfully traversing in/out. Ping6 works successfully. There is no firewall running anywhere(IPv4 or 6). Still get [r...@dig-client ~]# dig -6 a test.domain @bindserver6 +tcp socket.c:4922: 22/Invalid argument dig: isc_socket_connect: unexpected error I've got a closed lab testing BIND and I've got an interesting problem with IPv6 queries. Now I have 3 systems all running IPv4 and IPv6. IPv4 queries work fine across all systems. IPv6 UDP queries work fine as well. When I test IPv6 TCP queries I get the following failure: [r...@dig-client ~]# dig -6 a test.domain @bindserver6 +tcp socket.c:4922: 22/Invalid argument dig: isc_socket_connect: unexpected error Can you use other services over IPv6 in the lab? Also, what version of BIND are you using? With 9.6.1-P1 I'm not having any problems with an external query such as: dig -6 @ns.isc.afilias-nst.info isc.org soa +tcp I am using BIND 9.6.1-P1. Ping6 works, and I can run UDP based dig (+notcp) with no issues. IPv6 / TCP based queries fail. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ ___ 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
Re: SERVFAIL on 9.6.1-P1
Phillips, Dustin B (DBphillips) wrote:
Hello BIND users,
We experienced a SERVFAIL on a single domain this morning but were
able to resolve the issue by flushing the servers cache with ‘rndc flush’.
I gathered some debugs (below) and am hoping someone can shed light on
what might have been causing the failure.
Note: I replaced the real domain with “{domain removed}” in the debugs.
Before rndc flush:
23-Nov-2009 10:19:59.213 debug 3: client 24.217.29.1#42785: UDP request
23-Nov-2009 10:19:59.213 debug 3: client 24.217.29.1#42785: query
23-Nov-2009 10:19:59.213 debug 3: client 24.217.29.1#42785: replace
23-Nov-2009 10:19:59.213 debug 1: createfetch: {domain removed} A
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'):
create
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'): join
23-Nov-2009 10:19:59.214 debug 3: fetch 56b4cb0 (fctx 98757d0({domain
removed}/A)): created
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'): start
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'): try
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'):
cancelqueries
23-Nov-2009 10:19:59.214 debug 3: fctx 98757d0({domain removed}/A'):
getaddresses
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'):
no addresses
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'): done
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'):
stopeverything
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'):
cancelqueries
23-Nov-2009 10:19:59.215 debug 3: fctx 98757d0({domain removed}/A'):
sendevents
23-Nov-2009 10:19:59.215 debug 1: client 24.217.29.1#42785: query
failed (SERVFAIL) for {domain removed}/IN/A at query.c:4619
23-Nov-2009 10:19:59.215 debug 3: client 24.217.29.1#42785: error
23-Nov-2009 10:19:59.215 debug 3: client 24.217.29.1#42785: send
23-Nov-2009 10:19:59.215 debug 3: client 24.217.29.1#42785: sendto
23-Nov-2009 10:19:59.216 debug 3: client 24.217.29.1#42785: senddone
23-Nov-2009 10:19:59.216 debug 3: client 24.217.29.1#42785: next
23-Nov-2009 10:19:59.216 debug 3: client 24.217.29.1#42785: endrequest
23-Nov-2009 10:19:59.216 debug 2: fetch completed at resolver.c:2998
for {domain removed}/A in 0.001186: failure/success [domain:{domain
removed},referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:2,findfail:0,valfail:0]
23-Nov-2009 10:19:59.216 debug 3: fetch 56b4cb0 (fctx 98757d0({domain
removed}/A)): destroyfetch
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'):
shutdown
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'):
doshutdown
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'):
stopeverything
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'):
cancelqueries
23-Nov-2009 10:19:59.216 debug 3: fctx 98757d0({domain removed}/A'):
destroy
After rndc flush:
23-Nov-2009 10:20:07.047 debug 3: client 24.217.29.1#43324: UDP request
23-Nov-2009 10:20:07.047 debug 3: client 24.217.29.1#43324: query
23-Nov-2009 10:20:07.047 debug 3: client 24.217.29.1#43324: replace
23-Nov-2009 10:20:07.047 debug 1: createfetch: {domain removed} A
23-Nov-2009 10:20:07.048 debug 3: fctx 9875a30({domain removed}/A'):
create
23-Nov-2009 10:20:07.048 debug 3: fctx 9875a30({domain removed}/A'): join
23-Nov-2009 10:20:07.048 debug 3: fetch 9a6d2c8 (fctx 9875a30({domain
removed}/A)): created
23-Nov-2009 10:20:07.084 debug 3: fctx 9875a30({domain removed}/A'): start
23-Nov-2009 10:20:07.084 debug 3: fctx 9875a30({domain removed}/A'): try
23-Nov-2009 10:20:07.085 debug 3: fctx 9875a30({domain removed}/A'):
cancelqueries
23-Nov-2009 10:20:07.085 debug 3: fctx 9875a30({domain removed}/A'):
getaddresses
23-Nov-2009 10:20:07.086 debug 3: fctx 9875a30({domain removed}/A'): query
23-Nov-2009 10:20:07.086 debug 3: resquery 987b310 (fctx
9875a30({domain removed}/A)): send
23-Nov-2009 10:20:07.087 debug 3: resquery 987b310 (fctx
9875a30({domain removed}/A)): sent
23-Nov-2009 10:20:07.092 debug 3: resquery 987b310 (fctx
9875a30({domain removed}/A)): udpconnected
23-Nov-2009 10:20:07.092 debug 3: resquery 987b310 (fctx
9875a30({domain removed}/A)): senddone
23-Nov-2009 10:20:07.370 debug 3: resquery 987b310 (fctx
9875a30({domain removed}/A)): response
23-Nov-2009 10:20:07.370 debug 3: fctx 9875a30({domain removed}/A'):
noanswer_response
23-Nov-2009 10:20:07.370 debug 3: fctx 9875a30({domain removed}/A'):
cache_message
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'):
cancelquery
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'):
cancelqueries
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'): try
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'):
cancelqueries
23-Nov-2009 10:20:07.371 debug 3: fctx 9875a30({domain removed}/A'):
getaddresses
23-Nov-2009 10:20:07.372 debug 3: fctx 9875a30({domain removed}/A'):
Re: DIG -6 +TCP
Pamela Rock wrote: For all it's worth, using wireshark, I can see IPv6 UDP queries successfully traversing in/out. Ping6 works successfully. There is no firewall running anywhere(IPv4 or 6). Still get [r...@dig-client ~]# dig -6 a test.domain @bindserver6 +tcp socket.c:4922: 22/Invalid argument dig: isc_socket_connect: unexpected error Ok, when you're using wireshark do you ever see TCP6 packets leaving the box? Can you connect between machines using TCP6 for anything else? And, what OS(es) are you using? Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DIG -6 +TCP
Doug Barton wrote: Pamela Rock wrote: For all it's worth, using wireshark, I can see IPv6 UDP queries successfully traversing in/out. Ping6 works successfully. There is no firewall running anywhere(IPv4 or 6). Still get [r...@dig-client ~]# dig -6 a test.domain @bindserver6 +tcp socket.c:4922: 22/Invalid argument dig: isc_socket_connect: unexpected error Ok, when you're using wireshark do you ever see TCP6 packets leaving the box? Can you connect between machines using TCP6 for anything else? And, what OS(es) are you using? And, just in case you're not running what you expected... dig -v ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
loading zone: creating database: out of memory
CentOS release 5.4 (Final) + BIND 9.6.1-P1 Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 8G Memory Load 500,000 domains, the loading process, the following error: loading zone: creating database: out of memory 2009-11-24 万善义 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forwarding updates between views
On 23/11/09 18:05, Chris Buxton wrote: The internal-in view should have some log entry of the forwarded update. I'm not sure what category or severity level that would be, though. I could not find it in either the query log or the update log. Bug? Of course, if you were to start using signed updates (either TSIG or GSS-TSIG), you would know what key was used. The purpose is to provide a free ipv6-only playground that anyone may use. Normal updates from external clients are logged as intended. Feel free to add, modify or remove records under dyn.ipv6.chaz6.com. When security is required I do of course use keys! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: loading zone: creating database: out of memory
万善义 wrote: CentOS release 5.4 (Final) + BIND 9.6.1-P1 Intel(R) Xeon(R) CPU E5506 @ 2.13GHz 8G Memory Load 500,000 domains, the loading process, the following error: loading zone: creating database: out of memory 2009-11-24 万善义 Is there a question somewhere? Also, whats with the bold HTML? this is E-Mail, not http smime.p7s Description: S/MIME Cryptographic Signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
