Re: wget not resolving domain names

From: Paul Howarth (paul_at_city-fan.org)
Date: 11/01/05

  • Next message: Paul Smith: "Re: Automatic way of terminating a program" 
    Date: Tue, 01 Nov 2005 10:52:33 +0000
To: For users of Fedora Core releases <fedora-list@redhat.com>

    Cameron Beattie wrote:
    > I have the following issue where wget won't resolve a domain name the
    > first time I try it. It will only resolve the name once I do an nslookup.
    >
    > /etc/resolv.conf
    > nameserver 192.168.0.253
    >
    > ping fedoraproject.org
    > PING fedoraproject.org (152.3.183.74) 56(84) bytes of data.
    > 64 bytes from fedoraproject.org (152.3.183.74): icmp_seq=0 ttl=44
    > time=286 ms
    >
    > wget http://fedoraproject.org/extras/3/i386/plone-2.0.5-2.noarch.rpm
    > --05:11:00--
    > http://fedoraproject.org/extras/3/i386/plone-2.0.5-2.noarch.rpm
    > => `plone-2.0.5-2.noarch.rpm'
    > Resolving fedoraproject.org... 1.0.0.0
    > Connecting to fedoraproject.org|1.0.0.0|:80...
    >
    > nslookup
    >
    >> fedoraproject.org
    >
    > Server: 192.168.0.253
    > Address: 192.168.0.253#53
    >
    > Non-authoritative answer:
    > Name: fedoraproject.org
    > Address: 152.3.183.74
    >
    > wget http://fedoraproject.org/extras/3/i386/plone-2.0.5-2.noarch.rpm
    > --05:11:37--
    > http://fedoraproject.org/extras/3/i386/plone-2.0.5-2.noarch.rpm
    > => `plone-2.0.5-2.noarch.rpm'
    > Resolving fedoraproject.org... 152.3.183.74
    > Connecting to fedoraproject.org|152.3.183.74|:80... connected.
    >
    > I am using Fedora Core 3.
    >
    > I'm sure there is a very simple solution. Any help would be appreciated.

    Please post the output of:

    $ grep hosts /etc/nsswitch.conf

    Is the nameserver at 192.168.0.253 reliable?

    Try looking up an IP address that you haven't tried recently and see if
    it returns the same results every time, e.g.

    $ dig @192.168.0.253 www.uit.no
    $ dig @192.168.0.253 www.uit.no

    Paul. 

    -- 
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
  • Next message: Paul Smith: "Re: Automatic way of terminating a program"

    Relevant Pages

    • Re: Internal and external IP resolution
      ... The problem is that if the user for any reason looks for MAILSERVER.OURDOMAIN.COM while off the network "before" connecting internally the name will naturally be resolved by an external DNS from the ISP and will naturally resolve it to the external IP. ... If they boot up and correctly connect to the VPN before firing up Outlook or addressing MAILSERVER.OURDOMAIN.COM, the IP will be resolved properly by our internal DNS to 192.x.x.x ... As far as RPC over HTTPS I was under the assuption that I had to have the Exchange Server as the Global Catalog. ...
      (microsoft.public.windows.server.networking)
    • Generic host process for win32 services error message
      ... on for the first time I receive the "Generic host process for win32 services ... error message. ... tried everything I can think of to resolve this problem with no luck. ... Mike Miller ...
      (microsoft.public.windowsxp.help_and_support)
    • Generic host process for win32 services error message
      ... has a HP Laserjet 4100 printer and seiko lable printer series 100 connected ... on for the first time I receive the "Generic host process for win32 services ... error message. ... tried everything I can think of to resolve this problem with no luck. ...
      (microsoft.public.windowsxp.general)
    • Re: ProFTPd and reverse DNS
      ... > connecting to the machine did not resolve, I've checked into it, and apparently ProFTPd does ... > not check forward to reverse DNS mappings, and only resolves the IP address connecting. ...
      (Bugtraq)
    • RE: OfficeJet 7410 All-in-One & 2003 Terminal Services - HELP
      ... The person I was trying to resolve this for lost contact ... A Remote Desktop user with WinXP Pro SP2 with a locally installed ... >> Terminal Server and confirmed a correct driver install; ... >> connecting the 7410 to a laptop outside of our network and was able to ...
      (microsoft.public.windowsxp.work_remotely)