Shimon ... The stack does not perform DNS resolution. The applications handle it (even if by way of some library function). This is true in other TCP/IP implementations, not just VM TCP/IP: the apps resolve hostnames.
-- R; Shimon Lebowitz <[EMAIL PROTECTED]> Sent by: The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> 12/19/2006 12:59 PM Please respond to The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> From Shimon Lebowitz <[EMAIL PROTECTED]> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: DNS question Quoting Rob van der Heij <[EMAIL PROTECTED]>: > On 12/19/06, Shimon Lebowitz <[EMAIL PROTECTED]> wrote: > > > What am I forgetting? > > The TCPIP DATA goes on the 592 disk. It's the client code (e.g. PING, > TELNET) that has to talk to the DNS to translate the host name into an > IP address. The stack has no clue about that. <confused> I don't think I understand what you are saying. I put the altered version of TCPIP DATA on TCPIP2's (my test stack userid) so that the stack would see the DNS lines, doesn't PING run in the TCPIP2 user itself? The 191 is accessed ahead of 592, so doesn't TCPIP2 know about the DNS? </confused> > We used to say that it was a good idea to run the cache-only resolver > that comes with VM TCP/IP (i.e. NAMED) to avoid excessive DNS lookups > going outside VM. Some installations also used it to prime the cache > with a set of important host names (in case the outboard DNS was not > available). But the VM DNS implementation has become a bit dated, so > if you can you should probably avoid that route. Hmmmm.... "used to say it was a good idea".... "you should probably avoid that route"? I actually tried to start NAMSERV )or whatever the builtin DNS is called), including putting the two DNS server addresses in FORWARDERS(?), but it didn't help. I am home now, so I might not remember keywords correctly. Thanks for responding, Shimon ._._._*_|_*_*_*_*
