Craig I wish I could find it explicitly stated somewhere but both nslookup and dig only ever access external name servers. In other words dig behaves as if LOOKUP DNS was specified. Thus it never goes anywhere near a local name-to-address/address-to-name file (e.g. IPNODES) or set of files (e.g. derived from HOSTS.LOCAL).
The nearest I can get to documentation of this is the following from the Configuration Guide: <quote> 2.6.1.3.2 Resolver directives for dig The dig program uses the following resolver directives (TCPIP.DATA statements): domain/domainorigin search nameserver/nsinteraddr options ndots </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B3A0/2.6.1.3.2 This is a bit like "the dog that didn't bark in the night" in that you'll notice that LOOKUP is *not* mentioned. Incidentally, the best list for this type of question is the following: For IBMTCP-L subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBMTCP-L Chris Mason On Wed, 27 Jul 2011 16:03:16 -0400, Craig's Listserve account <[email protected]> wrote: >---------------- Begin Forwarded Message ---------------- >Subject: Another TCPIP RESOLVER question >Date Sent: Wednesday, July 27, 2011 3:54 PM >From: Craig Dudley <[email protected]> >To: IBM Mainframe Discussion List <[email protected]> > >Hi, >Maybe this is the correct account! > >I am having a problem with my z/OS 1.12 RESOLVER not using the >GLOBALIPNODES dataset(member) in the resolution of a TSO dig >command. > >I am using IPv4, and COMMONSEARCH, GLOBALTCPIPDATA, & >GLOBALIPNODES in my RESOLVER definitions. The dataset pointed >to by this by GLOBALTCPIPDATA and GLOBALIPNODES is the same >but using different members for each parameter. > >My GLOBALTCPIPDATA member defines a TCPIP.DATA file (in a member) >that contains: > >TRACE RESOLVER >TCPIPJOBNAME TCPIP >TSGOIT: HOSTNAME tsgoit >DOMAINORIGIN NH.GOV >NSINTERADDR 10.128.10.21 >NSINTERADDR 10.128.10.22 >NSPORTADDR 53 >RESOLVEVIA UDP >DATASETPREFIX TCPIP.ZOS >LOOKUP LOCAL DNS > >My GLOBALIPNODES member contains > >10.10.10.01 craig.test.gov > >When I do a TSO dig craig.test.gov, the resulting RESOLVER trace >does not show any indication that the RESOLVER is using my >GLOBALIPNODES member to resolve the dig command. > > >My question is why isn't the RESOLVER trace showing any attempt to >access my GLOBALIPNODES member to resolve the TSO dig craig.test.gov >command. > >The 1st part of my RESOLVER trace is below. > >-- >Craig Dudley >----------- 1st part of my RESOLVER trace: ---------------- > > >Resolver Trace Initialization Complete -> 2011/07/27 15:25:51.732241 > >res_init Resolver values: > Global Tcp/Ip Dataset = TCPIP.ZOS.PROFILE.PARMLIB(SNH1DA13) > Default Tcp/Ip Dataset = None > Local Tcp/Ip Dataset = None > Translation Table = TCPIP.ZOS.STANDARD.TCPXLBIN > UserId/JobName = SYB700 > Caller API = TCP/IP C Sockets > Caller Mode = EBCDIC > System Name = TSGOIT (from VMCF) > (G) DataSetPrefix = TCPIP.ZOS > (G) HostName = tsgoit > (G) TcpIpJobName = TCPIP > (G) DomainOrigin = NH.GOV > (G) NameServer = 10.128.10.21 > EDNS0 Support = Unknown > 10.128.10.22 > EDNS0 Support = Unknown > (G) NsPortAddr = 53 (G) ResolverTimeout = 5 > (G) ResolveVia = UDP (G) ResolverUdpRetries = 4 > (*) Options NDots = 1 > (G) Trace Resolver (*) SockNoTestStor > (*) AlwaysWto = NO (*) MessageCase = MIXED > (G) LookUp = LOCAL DNS > (*) Cache >res_init Succeeded >res_init Started: 2011/07/27 15:25:55.064856 >res_init Ended: 2011/07/27 15:25:55.064896 >*************************************************************************** >res_init Started: 2011/07/27 15:25:56.585524 >res_init Ended: 2011/07/27 15:25:56.585564 >*************************************************************************** >res_mkquery Started: 2011/07/27 15:25:57.107944 >res_mkquery(QUERY, craig.test.gov, C_IN, T_A) >res_mkquery created message: >* * * * * Beginning of Message * * * * * > Query Id: 6 > Flags: 00000001 00000000 > Flags set: recurDes > OpCode: QUERY > Response Code: NOERROR > > Number of Question RRs: 1 > Question 1: > craig.test.gov > Type (0X0001) T_A Class (0X0001) C_IN >* * * * * End of Message * * * * * >res_mkquery Ended: 2011/07/27 15:25:57.187633 >*************************************************************************** >res_send Started: 2011/07/27 15:25:57.220136 >res_send Name Server Capabilities > OpCode: QUERY > Response Code: NOERROR > > Number of Question RRs: 1 > Question 1: > craig.test.gov > Type (0X0001) T_A Class (0X0001) C_IN >* * * * * End of Message * * * * * >res_mkquery Ended: 2011/07/27 15:25:57.187633 >*************************************************************************** >res_send Started: 2011/07/27 15:25:57.220136 >res_send Name Server Capabilities > Name server 10.128.10.21 > EDNS0 Support = N/A > Queries sent = 1 > Failures = 0 > Percentage = 0% > Name server 10.128.10.22 > EDNS0 Support = N/A > Queries sent = 0 > Failures = 0 > Percentage = 0% >res_send Sending query to Name Server 10.128.10.21 >DNS Communication Started: 2011/07/27 15:25:57.220232 > BPX1SOC: RetVal = 0, RC = 0, Reason = 0x00000000, Type=IPv4 > BPX1STO: RetVal = 32, RC = 0, Reason = 0x00000000 > BPX1AIO Sched: RetVal = 1, RC = 0, Reason = 0x00000000 > BPX1AIO RECVMSG : From 10.128.10.21 > RetVal=107, RC=0, Reason=0x00000000 > UDP Data Length: 107 >res_send received data via UDP. Message received: >* * * * * Beginning of Message * * * * * > Query Id: 6 > Flags: 10000001 10000011 > Flags set: resp recurDes recurAvl > OpCode: QUERY > Response Code: NXDOMAIN > > Number of Question RRs: 1 > Question 1: > craig.test.gov > Type (0X0001) T_A Class (0X0001) C_IN > > Number of Answer RRs: 0 > Number of Authority RRs: 1 > Authority 1: > gov > Type (0X0006) T_SOA Class (0X0001) C_IN > TTL: 6379 (0 days, 1 hours, 46 minutes, 19 seconds) > a.gov-servers.net > nstld.verisign-grs.com > Serial: 1311786001 > Reresh: 3600 > > > >----------------- End Forwarded Message ----------------- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
