Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a problem with my Sendmail, ftp, pop, just about anything that trys to get the hostname from the remote system. I am not able to FTP into my server, because it is trying to get the hostname of my remote system, but my ISP seems to be stupid and can't get their DNS going right so my system can't be resolved, and my FTP connection times out before I can do anything. Same thing seems to be happening with SMTP, and POP, when I try to send or recieve my mail it takes forever to do so. What I am wondering is where I go to disable the name resolution, and make it so that FTP or other services don't need the hostname of the remote system, only the IP.
Just to clarify... you are getting time outs when you access your box externally via the WWW 'cos its not got an entry in your ISP's NS yeah?
If this is the case then you won't be able to 'disable resolution' as its not your software doing the resolving! If its the case that your box is trying to resolve IPs but can't do as your ISP's NS is shite then you will either need to wait for them to fix it or run your own NS.
If you temporarily need an external FQDN try using someone like http://www.dnydns.org to create one. That would solve any external problems, you'd just need to use the 'other' domain name.
HTH - a little calarification on the situation might be good though.
Here is the situation again in hopefully better terms:
I manage a hosted web server, it is a dedicated box so I am able to access it as root, but I access it remotely. This box is running RedHAt 7.0, and when I try to FTP into this box, I am unable to do so because my home computer's IP address is not able to resolve into a name. FTP try's to resolve the name, I am assuming, for logging purposes. When I visited the wu-ftpd webpage FAQ this is what I was able to find from http://www.wu-ftpd.org/wu-ftpd-faq.html#QA83:
Question: Logins to the ftp server take a long time, after that things run smooth
Answer: Possible causes: IDENT (RFC931) lookup is enabled in wu-ftpd. This has a timeout of 10 seconds. If the protocol (port 113) gets blocked by a firewall or suchlike, it will wait for timeout. If it is 30 seconds and you are using redhat 7.x with xinetd, disable AUTH in inetd as well. Any other time period: DNS is broken for the IP address the connection is coming from.
So what I did then is tried running an nslookup on my hosted machine for my home IP, and sure enough it can't resolve it. I also get a lot of the following messages in my log files (/var/log/messages) when I try to FTP in:
(these lines are all talking about not being able to resolve my home IP address, my home ISP nameservers are lame basically)
Jun 4 20:11:04 MYSERVER named[869]: Lame server on 'xxx.xxx.xxx.xxx.in-addr.arpa' (in 'xxx.xxx.xxx.in-addr.arpa'?): [xxx.xxx.xxx.xxx] 'NAMESERVER1.MYISP.COM'
Jun 4 20:11:05 MYSERVER named[869]: Lame server on 'xxx.xxx.xxx.xxx.in-addr.arpa' (in 'xx.xxx.xxx.in-addr.arpa'?): [xxx.xxx.xxx.xxx] 'NAMESERVER2.MYISP.COM'
Jun 4 20:11:10 MYSERVER named[869]: ns_forw: query(xxx.xxx.xxx.xxx.in-addr.arpa) All possible A RR's lame
So what is happening is, my home IP address cannot be resolved into a name, as a result my hosted box is timing out the connection because it will not let it past without resolving my home IP into a name. I hope this helps a little more. So my question is, how do I prevent wu-ftpd from requiring a resolvable IP, or trying to resolve the IP?
if uve got a static IP (now this is just an idea ok) try adding ure FQDN & IP addy to ure remote box's /etc/hosts and set resolve to order "hosts,dns(,nis)".
now in theory this should allow ure box to get a match off the hosts file, shouldnt it?
or am I talkin like a 4 yr old here? :-]
Originally posted by unSpawn if uve got a static IP (now this is just an idea ok) try adding ure FQDN & IP addy to ure remote box's /etc/hosts and set resolve to order "hosts,dns(,nis)".
now in theory this should allow ure box to get a match off the hosts file, shouldnt it?
or am I talkin like a 4 yr old here? :-]
Can we connect to the ftp server from a different internet connection/machine/city? It appears that the problem is on the client side, but a simple test sould be able to verify this.
We talking like we might be having a named running on the client side as well? Could get nasty if the ISP is using DHCP and we have decalred our own zone info. What happens on the host side in the following scenario:
/etc/resolv.conf is pointing to your IPSs name server..
domain=ispdomain.com
nameserver=xxx.xxx.xxx.xxx # the ip addr of your ISPs name server
search=ispdomain.com
do a 'host -va xxx.xxx.xxx.xxx' for your ip address. This should resolv to your in-addr.arpa record. You can also go to samspade.org and do a "Scan rDNS" which will lookup your ipblock. If the whole block comes up as 'bogus rDNS' then it's possible your ISP is suffering from a cranial-rectal inversion. You can do this from any connection and you should get the same resolution from that IP. If reply is different on your client then you should check you in-addr.arpa entries.
If your ISP is using DHCP - have you set up as a static address? Even though they may have given you a static IP as port of your service agreement, some still require you to use DHCP to verify your MAC address (as it is used in some 'authentication' schemes). A major pain in the *.
Can you change your in-addr.arpa record through your ISP? (I can on mine.)
Is there anything funky going on over at the server side? Can you establish an ftp connection from the server side?
OK I just realized I replied to unSpawn's reply by mistake. Being that I am essentially lazy, I won't re-submit. Please ignore this error and continue as if nothing happened. Move along - nothing to see here.
Okay when I say my ISP I am talking about my home provider, when I say server I am talking about my hosted dedicated box. My server has no problems on it whatsoever, my ISP has lame nameservers, and as a result my server timesout the connection when I Try to connect through FTP because it can't resolve my home IP into an "in-addr.arpa". I have no problem ftp'ing into, for example, ftp.redhat.com. I also have no problem ftp'ing into my server from my server. I know the problem here is my ISP or "Client Side", my server "Remote Host" is configured just fine, except it denies access to FTP if it can't resolve the client IP into an in-addr.arpa.
i have the exactly same problem, running a dedicated server and having those tremendously long ftp start problem from the client's machine (local network, local ip). it can't resolve the ip...
so, if anybody found a solution to this, i'd be very happy if you could let me know - and, oh, please treat me as a linux dummy: i'm designer trying to do some serverside stuff. know what i mean? ;-) thanks a lot!!!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.