On Fri, Oct 15, 2004 at 12:02:31PM +0000, Blechinger Robert wrote:
> >Description:
> the command "host" doesn't work. ALL lookups ends in failure.
> even if you specify an external nameserver.
> nameresoltion of other system commands are working fine ( netstat, who, nslookup, arp )
> 
> on 5.2.1 there was no problem. this problem occoured after upgrading to 5.3beta AND updating time_t to 64bits. i followed excatly what is written in  /usr/src/UPDATING.64BTT
> 
> i upgraded severaltimes to newest beta number, and also cleaned the whole source tree an rebuild multiple times "world, kernel"
> 
> Here a short part of CLI:
> rblechinger@nuntius:~>host www.google.de.
> Host not found, try again.
> rblechinger@nuntius:~>host www.google.de. 83.120.1.2
> Using domain server 83.120.1.2:

It's working fine for me on machines that have been upgraded in a
manner like you describe.

Are you sure you're using the system's version of the host command?
Can you check by doing 'which host' to make sure it's not a version
that got installed as part of a port please?  It should say "/usr/bin/host".

-- 
						Ken Smith
- From there to here, from here to      |       kensmith@cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

Hi Ken,

On Fri, 15 Oct 2004 08:50:17 -0400
Ken Smith <kensmith@cse.Buffalo.EDU> wrote:

> It's working fine for me on machines that have been upgraded in a
> manner like you describe.
> 
> Are you sure you're using the system's version of the host command?
> Can you check by doing 'which host' to make sure it's not a version
> that got installed as part of a port please?  It should say "/usr/bin/host".

no, it was build by world.

rblechinger@nuntius:~>which host
/usr/bin/host
rblechinger@nuntius:~>

i can give you access to that machine if you need.... or do what ever you
need.

-- 
Blechinger Robert
isp-service ag - Network Engineering

- We are network admins, to us data is just protocol overhead -

On Fri, Oct 15, 2004 at 12:02:31PM +0000, Blechinger Robert wrote:
> rblechinger@nuntius:~>host -vd www.google.de.
> ;; res_nmkquery(QUERY, www.google.de, IN, A)
> ;; res_send()
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53801
> ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;;      www.google.de, type = A, class = IN
> ;; Querying server (# 1) address = 83.120.1.2
> ;; new DG socket
> res_send: select: Invalid argument
> ;; Querying server (# 2) address = 83.120.2.7
> ;; new DG socket
> res_send: select: Invalid argument
> ;; Querying server (# 1) address = 83.120.1.2
> ;; new DG socket
> res_send: select: Invalid argument
> ;; Querying server (# 2) address = 83.120.2.7
> ;; new DG socket
> res_send: select: Invalid argument
> res_nsend failed
> Host not found, try again.
> rblechinger@nuntius:~>host -vd www.google.de. 83.120.1.2
> Using domain server 83.120.1.2:

Thanks for checking the path to host was right.  Sorry but I had to
ask. :-)

Given the complaints from select above the next thing I'd like to
check is your network interface settings.  Can you send the lines
from /etc/rc.conf that configure the net interface and the output
of 'ifconfig' please?  If you want to either send them as private
email or replace the IP/netmask with "x" characters so that info
doesn't get logged publically that's fine.

And are you using any sort of firewalling?  ipfw or something along
those lines?

Thanks.

-- 
						Ken Smith
- From there to here, from here to      |       kensmith@cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |

Ken,

On Fri, 15 Oct 2004 09:16:50 -0400
Ken Smith <kensmith@cse.Buffalo.EDU> wrote:

> Thanks for checking the path to host was right.  Sorry but I had to
> ask. :-)

no problem. thats ok.

> Given the complaints from select above the next thing I'd like to
> check is your network interface settings. 

rblechinger@nuntius:~>ifconfig
hme0: flags=108843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        options=b<RXCSUM,TXCSUM,VLAN_MTU>
        inet 83.120.1.12 netmask 0xffffffe0 broadcast 83.120.1.31
        inet6 fe80::a00:20ff:fed1:ddd1%hme0 prefixlen 64 scopeid 0x1
        inet 83.120.1.11 netmask 0xffffffff broadcast 83.120.1.11
        inet6 2001:1b20:1000:2::12 prefixlen 64
        inet6 2001:1b20:1000:2::11 prefixlen 64
        ether 08:00:20:d1:dd:d1
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
rblechinger@nuntius:~>

defaultrouter="83.120.1.1"
hostname="nuntius.ffm.as8665.net"
ifconfig_hme0="inet 83.120.1.12/27"
ifconfig_hme0_alias0="inet 83.120.1.11/32"
#
ipv6_enable="YES"
ipv6_ifconfig_hme0="2001:1b20:1000:0002::12/64"
ipv6_ifconfig_hme0_alias0="2001:1b20:1000:0002::11/64"
ipv6_defaultrouter="2001:1b20:1000:0002::1"

the network works quite fine, no problems detected till now. only with 5.2.1
there where some negative times in traceroute, but that seems to be solved.


> And are you using any sort of firewalling?  ipfw or something along
> those lines?

no, its complete open. ( hm :) i have to be carefull to say that on a
mailinglist *g* )

rblechinger@nuntius:~>sudo ipfw list
65535 allow ip from any to any
rblechinger@nuntius:~>

ipfilter is not enabled by kernel, so even no ipfilter rules.... and yes..the
nameserver are reachabel :)


-- 
Blechinger Robert
isp-service ag - Network Engineering

- We are network admins, to us data is just protocol overhead -

Hi Ken,

sorry for making trouble. now i found that problem.
somebody made the entry "NO_BIND=true" in the make.conf
problem is that more people have access to this machine.

now, after upgrading from 5.2.1 to 5.3 and changing from 32->64bit
and rebuild bind9 to the system, "host" from former versions doesn't work
anymore. normaly it is build by "world" but...when entry in make.conf
"NO_BIND" ...sure.no bind and also no "host" is build and not updates the old
"host" which is now invalid.

sorry for that, i saw this entry when debugging other things :(

Thanks Robert


-- 
Blechinger Robert
isp-service ag - Network Engineering

- We are network admins, to us data is just protocol overhead -

Comment 6 Marius Strobl 2005-02-28 12:09:17 UTC

State Changed
From-To: open->closed


Not a bug, originator found local configuration problem.