Re: dig query
> AD is set when authentication is successful by the server > to whom you > are sending the query. The "+noadflag" says don't set > the AD bit in the > outbound query (which is the default). > > AlanC > Thanks. Based on that, the following: dig +adflag gov produces: flags: qr rd ra ad; Does that imply that +adflag sets the ad bit on the query and the response where +dnssec only sets the ad bit on the responce? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig query
The following dig query dig gov +dnssec +noadflag @10.10.10.1 produces the following flags in the header section: ;; flags: qr rd ra ad; Question - what is the relation with the +dnssec and +noadflag options in the query. I would think the query would produce a signed response with no ad bit in the header section. Why does ad show up when I specify +noadflag? Thanks!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 TCP
> I suspect your error has more to do with the value of the > IPv6 > address and sanity checks in the Linux kernel than with > anything > else. Use a allocated address or generate a ULA > prefix for testing > and use that. > Mark - you are right on the money!! I changed my IPv6 address, now everything works as it should!! Thanks for your help!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 TCP
--- On Tue, 12/29/09, Alan Clegg wrote: > From: Alan Clegg > Subject: Re: IPv6 TCP > To: "Pamela Rock" > Date: Tuesday, December 29, 2009, 9:34 AM > Pamela Rock wrote: > > > [r...@test /]# dig ip6.test.com @bind6 +tcp > +short socket.c:4922: 22/Invalid argument dig: > isc_socket_connect: > > unexpected error > > > > That last query never leaves the client resolver so > the DNS does not > > see it. Using wireshark, there is no traffic > between client and > > server. > > > > I'm stumped. > > If you dig @ another IPv6 server, does it work? > Does: > > dig +norec @2001:500:2f::f > F.ROOT-SERVERS.NET. a > > provide an answer? > This is a totally closed network. There is no access to anything. > AlanC > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 TCP
--- On Mon, 12/28/09, Kevin Oberman wrote: > From: Kevin Oberman > Subject: Re: IPv6 TCP > To: "Pamela Rock" > Cc: "Mark Andrews" , "Chuck Anderson" , > bind-users@lists.isc.org > Date: Monday, December 28, 2009, 10:08 PM > > Date: Mon, 28 Dec 2009 18:02:29 > -0800 (PST) > > From: Pamela Rock > > > > > > > > --- On Mon, 12/28/09, Mark Andrews > wrote: > > > > > From: Mark Andrews > > > Subject: Re: IPv6 TCP > > > To: "Pamela Rock" > > > Cc: "Kevin Oberman" , > "Chuck Anderson" , bind-users@lists.isc.org > > > Date: Monday, December 28, 2009, 8:22 PM > > > > > > In message <475084.65186...@web110304.mail.gq1.yahoo.com>, > > > Pamela Rock writes: > > > > This query is to anyone in general, based on > the > > > previous dig statement, do= > > > > es the following command make sense?? > > > > > > > > dig -6 www.es.net @some:ipv6:address +tcp > > > > > > > > I'm wondering if the combination of -6, > > > @some:ipv6:address, and +tcp even m= > > > > ake sense. That is ultimately what I'm > trying to > > > achieve. > > > > > > Yes, it make sense. The following will retrieve > the > > > SOA record > > > from ns-ext.isc.org using its IPv6 address over > tcp. > > > If you put a > > > literal IPv6 address rather than a name then the > -6 is not > > > needed. > > > > That's it!! So you are saying if I can use > either -6 or > > MY:IPv6:Address, but I don't have to use both? > Is that accurate? If > > so, that resolves the issue. > > If you tell dig(1) to query an IPv6 address, it has no > choice but to > use IPv6, so -6 is unnecessary and -4 is an error. The only > reason > for the -4 and -6 options is to force that protocol to be > used when a > name is provided and it has both v4 and v6 addresses. > > That said, using -6 with an IPv6 address should not cause a > problem. It > certainly works fine for me. Yeah, you're right, it still does not work even with the -6 left off. I thought that would provide the correct response... This works... [r...@test /]# dig ip6.test.com @bind6 +notcp +short e:1900:4545:3:200:f8ff:fe21:67cf This does not... [r...@test /]# dig ip6.test.com @bind6 +tcp +short socket.c:4922: 22/Invalid argument dig: isc_socket_connect: unexpected error That last query never leaves the client resolver so the DNS does not see it. Using wireshark, there is no traffic between client and server. I'm stumped. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley > Lab) > E-mail: ober...@es.net > Phone: +1 510 > 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D > EBB3 987B 3751 > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 TCP
--- On Mon, 12/28/09, Mark Andrews wrote: > From: Mark Andrews > Subject: Re: IPv6 TCP > To: "Pamela Rock" > Cc: "Kevin Oberman" , "Chuck Anderson" , > bind-users@lists.isc.org > Date: Monday, December 28, 2009, 8:22 PM > > In message <475084.65186...@web110304.mail.gq1.yahoo.com>, > Pamela Rock writes: > > This query is to anyone in general, based on the > previous dig statement, do= > > es the following command make sense?? > > > > dig -6 www.es.net @some:ipv6:address +tcp > > > > I'm wondering if the combination of -6, > @some:ipv6:address, and +tcp even m= > > ake sense. That is ultimately what I'm trying to > achieve. > > Yes, it make sense. The following will retrieve the > SOA record > from ns-ext.isc.org using its IPv6 address over tcp. > If you put a > literal IPv6 address rather than a name then the -6 is not > needed. That's it!! So you are saying if I can use either -6 or MY:IPv6:Address, but I don't have to use both? Is that accurate? If so, that resolves the issue. > > % dig -6 dv.isc.org soa @ns-ext.isc.org +tcp > > ; <<>> DiG 9.3.6-P1 <<>> -6 > dv.isc.org soa @ns-ext.isc.org +tcp > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, > id: 1588 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, > ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;dv.isc.org. > IN SOA > > ;; ANSWER SECTION: > dv.isc.org. > 3600 IN > SOA bsdi.dv.isc.org. marka.isc.org. > 2007103117 86400 21600 2419200 86400 > > ;; AUTHORITY SECTION: > dv.isc.org. > 86400 IN > NS ns-int.isc.org. > dv.isc.org. > 86400 IN > NS ns-ext.isc.org. > > ;; Query time: 218 msec > ;; SERVER: 2001:4f8:0:2::13#53(2001:4f8:0:2::13) > ;; WHEN: Tue Dec 29 12:15:00 2009 > ;; MSG SIZE rcvd: 117 > > % > > I suspect your error has more to do with the value of the > IPv6 > address and sanity checks in the Linux kernel than with > anything > else. Use a allocated address or generate a ULA > prefix for testing > and use that. > > 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
Re: IPv6 TCP
--- On Mon, 12/28/09, Kevin Oberman wrote: > From: Kevin Oberman > Subject: Re: IPv6 TCP > To: "Pamela Rock" > Cc: bind-users@lists.isc.org, "Chuck Anderson" > Date: Monday, December 28, 2009, 6:07 PM > > Date: Mon, 28 Dec 2009 13:31:50 > -0800 (PST) > > From: Pamela Rock > > Sender: bind-users-bounces+oberman=es@lists.isc.org > > > > --- On Mon, 12/28/09, Chuck Anderson > wrote: > > > > > From: Chuck Anderson > > > Subject: Re: IPv6 TCP > > > To: bind-users@lists.isc.org > > > Date: Monday, December 28, 2009, 3:58 PM > > > On Mon, Dec 28, 2009 at 07:56:56AM > > > -0800, Pamela Rock wrote: > > > > I posted this query a while ago but have not > yet been > > > able to resolve the issue... > > > > > > > > I have a DNS server and client that can ping > each > > > other using ping6. The following query works: > > > > > > > > dig -6 test.com +notcp > > > > > > > > When I query TCP with IPv6 I get the > following error: > > > > > > > > r...@test:/home/janderson/bind-9.6.1-P1 dig > -6 > > > test.com @bind6 +tcp > > > > socket.c:4922: 22/Invalid argument > > > > dig: isc_socket_connect: unexpected error > > > > > > I get this with the stock CentOS 5.4 dig: > > > > > > # rpm -qf `which dig` > > > bind-utils-9.3.6-4.P1.el5_4.1 > > > > I am running Red Hat 5 / 64 bit and I had to compile > > openssl-0.9.8k.tar to get a clean BIND 9.6.1-P1 > configure. > > > > My build process looks like the following > > named[3921]: built with '--enable-threads' > '--with-openssl=/usr/local/ssl/bin' '--enable-ipv6' > > > > What's wierd in that PING6 works and DIG IPv6 + UDP > works as well. > > DIG IPv6 + TCP fails. > > > > If anyone has 9.6.1-P1 and can run an IPv6 / TCP based > dig > > successfully, I'd be interested in knowing about your > platform. What > > O/S, HW, etc did you use to build BIND? > > Seems to work for me. FreeBSD 8.0, bind 9.6.1-P2 (P1 is > obsolete), > OpenSSL 0.9.8k. I've had no problems at all. I can even get > the > signatures, though we have not published any trust anchors, > so you can't > really use them, yet. > > I built the standard FreeBSD port with openssl, threads, > SIGCHASE, and > IPv6. Nothing special. > > > dig -6 www.es.net @ns1.es.net +tcp +dnssec > This query is to anyone in general, based on the previous dig statement, does the following command make sense?? dig -6 www.es.net @some:ipv6:address +tcp I'm wondering if the combination of -6, @some:ipv6:address, and +tcp even make sense. That is ultimately what I'm trying to achieve. > ; <<>> DiG 9.6.1-P2 <<>> -6 > www.es.net @ns1.es.net +tcp +dnssec > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, > id: 12531 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 4, > ADDITIONAL: 13 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;www.es.net. > IN A > > ;; ANSWER SECTION: > www.es.net. > 600 IN > CNAME www2.es.net. > www.es.net. > 600 IN > RRSIG CNAME 5 3 600 2010010009 > 2009122819 41782 es.net. > odSa/PcvfYH1UM+GPxi+mahnTisgn6rL9apCpHm0y6SLIzmpHycP+Ph2 > cA4aXNCA4736qWU7/MScHBul7cWsc94VJxE89wVw6GkDIu58I9/NiVBD > Tl6nfTZCJ3PyIHWEx2sFHMZKhiw6nIi7SBWj9RwkDB0jU6K8J9C5ge2s > 5r8= > www2.es.net. > 86400 IN > A 198.128.3.112 > www2.es.net. > 86400 IN > RRSIG A 5 3 86400 2010010009 > 2009122819 41782 es.net. > FGJKOxfkG7m3zKd0R0/s6hDCTSZP66oGxQxWXjeObtPOtKgAsFUACQbF > CZ/FRGMS+ryu6fC2C0DIePKYqeXGT5QSpcUi9t5iCY72ccRHG34hPSGr > nJHS+VrWENmrJ/I6X4aq/hdIXvpBz5ePgBl5w34toWDFoIyUJcpUkxUn > 9+k= > > ;; AUTHORITY SECTION: > es.net. > 600 > IN NS ns1.es.net. > es.net. > 600 > IN NS ns-aoa.es.net. > es.net. > 600 > IN NS ns-lvk.es.net. > es.net. > 600 > IN RRSIG NS 5 2 600 > 2010010009 2009122819 41782 es.net. > Y5StioMeHIdl74pI4ch+blK5q924ozUbDR5Fwz7Mfk+TOiIheRfPg2X4 > wuigN+0MfC5aE7HRmG/86mki8FUDY0LyzcO5aJFc5rHVHYjDBgBLh9Q5 > 2STPPQN6jkNki9Ux7WDeV79Fi8fRFJKP4q6bMdGB5x56um+0zXMiuk3E > za4= > > ;; ADDITIONAL SECTION: > ns1.es.net. > 86400 IN > A 198.128.2.10 >
Re: IPv6 TCP
--- On Mon, 12/28/09, Chuck Anderson wrote: > From: Chuck Anderson > Subject: Re: IPv6 TCP > To: bind-users@lists.isc.org > Date: Monday, December 28, 2009, 3:58 PM > On Mon, Dec 28, 2009 at 07:56:56AM > -0800, Pamela Rock wrote: > > I posted this query a while ago but have not yet been > able to resolve the issue... > > > > I have a DNS server and client that can ping each > other using ping6. The following query works: > > > > dig -6 test.com +notcp > > > > When I query TCP with IPv6 I get the following error: > > > > r...@test:/home/janderson/bind-9.6.1-P1 dig -6 > test.com @bind6 +tcp > > socket.c:4922: 22/Invalid argument > > dig: isc_socket_connect: unexpected error > > I get this with the stock CentOS 5.4 dig: > > # rpm -qf `which dig` > bind-utils-9.3.6-4.P1.el5_4.1 I am running Red Hat 5 / 64 bit and I had to compile openssl-0.9.8k.tar to get a clean BIND 9.6.1-P1 configure. My build process looks like the following named[3921]: built with '--enable-threads' '--with-openssl=/usr/local/ssl/bin' '--enable-ipv6' What's wierd in that PING6 works and DIG IPv6 + UDP works as well. DIG IPv6 + TCP fails. If anyone has 9.6.1-P1 and can run an IPv6 / TCP based dig successfully, I'd be interested in knowing about your platform. What O/S, HW, etc did you use to build BIND? > > # dig -6 test.com +notcp > dig: add_nameserver failed > ___ > 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: IPv6 TCP
IPTables and IP6Tables are turned off and not running. There is no other firewalls or filtering routers between DNS clients and servers. --- On Mon, 12/28/09, Rick Dicaire wrote: > From: Rick Dicaire > Subject: Re: IPv6 TCP > To: "Pamela Rock" > Cc: bind-users@lists.isc.org > Date: Monday, December 28, 2009, 12:57 PM > On Mon, Dec 28, 2009 at 10:56 AM, > Pamela Rock > wrote: > > When I query TCP with IPv6 I get the following error: > > Check client machine firewall. > > -- > aRDy Music and Rick Dicaire present: > http://www.ardynet.com > http://www.ardynet.com:9000/ardymusic.ogg.m3u > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
IPv6 TCP
I posted this query a while ago but have not yet been able to resolve the
issue...
I have a DNS server and client that can ping each other using ping6. The
following query works:
dig -6 test.com +notcp
When I query TCP with IPv6 I get the following error:
r...@test:/home/janderson/bind-9.6.1-P1 dig -6 test.com @bind6 +tcp
socket.c:4922: 22/Invalid argument
dig: isc_socket_connect: unexpected error
The query never leaves the client so the server never logs anything and I get
the same result if I issue the dig command from the client or DNS server.
Config details follow
O/S => RH 5 64-bit
r...@test:/etc uname -a
Linux test 2.6.18-164.2.1.el5 #1 SMP Mon Sep 21 04:37:42 EDT 2009 x86_64 x86_64
x86_64 GNU/Linux
BIND Version - version: 9.6.1-P1
Configured with the following options:
built with '--enable-threads' '--with-openssl=/usr/local/ssl/bin'
'--enable-ipv6'
named.conf options
options {
directory "/var/named";
version none;
recursion yes;
allow-recursion { 10.10.10.0/24; };
listen-on { 10.10.0.1; };
listen-on-v6 { aa10::b214:4cdf:ad7d:12a; };
};
Thanks!!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: strange dig behavior
--- On Sun, 12/20/09, Barry Margolin wrote:
> From: Barry Margolin
> Subject: Re: strange dig behavior
> To: comp-protocols-dns-b...@isc.org
> Date: Sunday, December 20, 2009, 10:59 PM
> In article ,
> Pamela Rock
> wrote:
>
> > I've got the following three scenarios
> >
> > The client can query a domain A residing on a
> recursive name server.
>
> What do you mean by a domain "residing" on a recursive
> nameserver? If a
> domain resides on a server, the server should be
> authoritative for that
> domain.
>
> >
> > The client can query a domain B on an authratative
> name server.
> >
> > When client queries domain B through the RNS, a
> Status: refused results.
> >
> > I don't know what is causing the refused. IP
> tables is off everywhere, and
> > there are no ACL's on routers or firewalls.
> >
> > The only error I'm seeing is the following in the
> debug log
> >
> > 20-Dec-2009 19:21:09.443 query-errors: debug 3: client
> 172.16.0.5#41484:
> > query failed (REFUSED) for test.com/IN/A at
> query.c:3882
> >
> > I'm running bind 9.6.1 on RH ES 5 64 bit O/S.
> Any ideas? Thanks!!
>
> Is that log on the recursive nameserver or the
> authoritative nameserver?
>
> If it's on the recursive server, is the client in the
> allow-recursion
> ACL on the server?
I did not have allow-recursion turned on. I turned it on and it worked.
Thanks!! So "recursion yes;" was not enough. I also had to "allow-recursion {
10.10.1.1; }' to the specific client IP as well.
Thanks!!
>
> If it's on the authoritative server, is the recursive
> server in the
> allow-query ACL?
>
> --
> Barry Margolin, bar...@alum.mit.edu
> Arlington, MA
> *** PLEASE don't copy me on replies, I'll read them in the
> group ***
> ___
> 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
strange dig behavior
I've got the following three scenarios The client can query a domain A residing on a recursive name server. The client can query a domain B on an authratative name server. When client queries domain B through the RNS, a Status: refused results. I don't know what is causing the refused. IP tables is off everywhere, and there are no ACL's on routers or firewalls. The only error I'm seeing is the following in the debug log 20-Dec-2009 19:21:09.443 query-errors: debug 3: client 172.16.0.5#41484: query failed (REFUSED) for test.com/IN/A at query.c:3882 I'm running bind 9.6.1 on RH ES 5 64 bit O/S. Any ideas? Thanks!! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
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: 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
DIG -6 +TCP
Hit the wrong key, sorry about that... 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 Any ideas what would be causing this? Thanks. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DIG -6 +TCP
I've got 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Fw: RE: dnssec enabled recursive server
t; 10.10.10.10#50188: recursion available > 23-Oct-2009 16:47:28.784 client: debug 3: client > 10.10.10.10#50188: query > 23-Oct-2009 16:47:28.784 security: debug 3: client > 10.10.10.10#50188: query (cache) 'www.123xyz.TLD/ANY/IN' > approved > 23-Oct-2009 16:47:28.785 client: debug 3: client > 10.10.10.10#50188: replace > 23-Oct-2009 16:47:28.785 general: debug 3: clientmgr > @0x2b8f4e86a3b8: createclients > 23-Oct-2009 16:47:28.785 general: debug 3: clientmgr > @0x2b8f4e86a3b8: recycle > 23-Oct-2009 16:47:28.785 resolver: debug 1: createfetch: > www.123xyz.TLD ANY > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): create > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): join > 23-Oct-2009 16:47:28.785 resolver: debug 3: fetch > 0x2b8f4e85c830 (fctx 0x2b167010(www.123xyz.TLD/ANY)): > created > 23-Oct-2009 16:47:28.785 client: debug 3: client @0xd50050: > udprecv > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): start > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): try > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): cancelqueries > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): getaddresses > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): query > 23-Oct-2009 16:47:28.785 resolver: debug 3: resquery > 0x2b16e010 (fctx 0x2b167010(www.123xyz.TLD/ANY)): > send > 23-Oct-2009 16:47:28.785 general: error: socket.c:4922: > unexpected error: > 23-Oct-2009 16:47:28.785 general: error: 22/Invalid > argument > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): done > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): stopeverything > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): cancelqueries > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): sendevents > 23-Oct-2009 16:47:28.785 query-errors: debug 1: client > 10.10.10.10#50188: query failed (SERVFAIL) for > www.123xyz.TLD/IN/ANY at query.c:4619 > 23-Oct-2009 16:47:28.785 client: debug 3: client > 10.10.10.10#50188: error > 23-Oct-2009 16:47:28.785 client: debug 3: client > 10.10.10.10#50188: send > 23-Oct-2009 16:47:28.785 client: debug 3: client > 10.10.10.10#50188: sendto > 23-Oct-2009 16:47:28.785 client: debug 3: client > 10.10.10.10#50188: senddone > 23-Oct-2009 16:47:28.785 client: debug 3: client > 10.10.10.10#50188: next > 23-Oct-2009 16:47:28.785 client: debug 3: client > 10.10.10.10#50188: endrequest > 23-Oct-2009 16:47:28.785 query-errors: debug 2: fetch > completed at resolver.c:3015 for www.123xyz.TLD/ANY in > 0.000483: unexpected error/success > [domain:.,referral:0,restart:1,qrysent:0,timeout:0,lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] > 23-Oct-2009 16:47:28.785 resolver: debug 3: fetch > 0x2b8f4e85c830 (fctx 0x2b167010(www.123xyz.TLD/ANY)): > destroyfetch > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): shutdown > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): doshutdown > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): stopeverything > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): cancelqueries > 23-Oct-2009 16:47:28.785 resolver: debug 3: fctx > 0x2b167010(www.123xyz.TLD/ANY'): destroy > 23-Oct-2009 16:47:28.802 client: debug 3: client > 10.10.10.10#56597: UDP request > 23-Oct-2009 16:47:28.802 security: debug 3: client > 10.10.10.10#56597: request is not signed > 23-Oct-2009 16:47:28.802 security: debug 3: client > 10.10.10.10#56597: recursion available > 23-Oct-2009 16:47:28.802 client: debug 3: client > 10.10.10.10#56597: query > 23-Oct-2009 16:47:28.802 security: debug 3: client > 10.10.10.10#56597: query (cache) 'TLD/DNSKEY/IN' approved > 23-Oct-2009 16:47:28.802 client: debug 3: client > 10.10.10.10#56597: send > 23-Oct-2009 16:47:28.802 client: debug 3: client > 10.10.10.10#56597: sendto > 23-Oct-2009 16:47:28.802 client: debug 3: client > 10.10.10.10#56597: senddone > 23-Oct-2009 16:47:28.802 client: debug 3: client > 10.10.10.10#56597: next > 23-Oct-2009 16:47:28.802 client: debug 3: client > 10.10.10.10#56597: endrequest > 23-Oct-2009 16:47:28.802 client: debug 3: client @0xd25b00: > udprecv > > > &
dnssec enabled recursive server
This environment is in a lab. I have a DNSSEC enabled server with a signed .TLD zone (again, in a lab). I have a client that can accurately run queries against the signed .TLD zone. So this works... DNSSEC Enabled Client => DNSSEC Enabled .TLD I'm trying to put a recursive BIND 9.6.1-P1 server between .TLD and the client. DNSSEC Enabled Client => Recursive BIND => DNSSEC Enabled .TLD I setup the cache file on the recursive BIND to point all root servers to the DNSSEC Enabled .TLD. I enabled dnssec-enable and dnssec-validation in the named.conf. I pulled the keys from DNSSEC Enabled .TLD using dig +dnssec com @test.server.TLD and put them in the named.conf. Yet my recursive DNSSEC 9.6.1 server does not answer DNSSEC queries from the client. Any hints or clues to how to make the recursive DNSSEC work would be appreciated. Thanks in advanced. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
