Adding hostname and its IP into its own /etc/hosts file

jpollard · 11-01-2016, 05:49 PM

Quote:

Originally Posted by jefro

If I had sat connection, I'd make the 50 or so common sites in hosts file and be sure edit that into a good hosts blocking file. You don't need all those ad's tearing up your bandwidth.
http://winhelp2002.mvps.org/hosts.htm

You can speed up lookups as most systems go to hosts file first to resolve an IP. Local lookup is much faster than web searches. You can speed up good sites and block bad sites or trivial ad sites.

Actually, you could run your own caching server... The problem with entries in the /etc/hosts file for internet servers is that the specific server you connect to may be super busy (or even down). DNS allows the same name to be assigned to multiple IP numbers (usual limit is about 35 for IPv4), and the server will rotate the numbers to help balance the load. The /etc/hosts file will only use the first entry that matches the name.

Once your caching server gets the name/ip numbers it will provide them locally until the DNS lifetime is reached. This allows the servers to migrate to new IP numbers without having you manually edit the /etc/hosts file.

jefro · 11-01-2016, 08:39 PM

I think you'd end up using a lot of data making a local dns server still. They only get so many bits over the sat. I ran my house on a wifi for a while and was in a similar boat trying to limit data use. (text browser helps a lot)

jpollard · 11-01-2016, 10:02 PM

It saves a good bit. The DNS entries only get downloaded once for its entire lifetime. And if it changes, then the updates will be downloaded.

jefro · 11-02-2016, 03:29 PM

It is a solid choice to consider using a local stub.
Either choice might be better than constant sat use of name resolution I'd think.

lazydog · 11-03-2016, 07:20 AM

Quote:

Originally Posted by tronayne

Of course. However, I have HughesNet Gen4 (EchoStar XVII) satellite service (with light velocity delay built in) and HughessNet DNS servers are faster than any of the other ones in my circumstance. If there's a weather problem (there is every so often) it ain't going to be working in any event, you just wait, there is no alternative where I live.
Keep in mind that it's 22,236 miles up, 22K down, do something, 22K back up and 22K down to me.

Well, I actually don't. The normal connection with the laptop is an Ethernet cable to the router but, if I have to use wi-fi, I have a /etc/resolv.con.bak that, if DHCP rears its ugly head, is a simple copy to /etc/resolv.conf. Also, I do not run DHCP on anything, everything (including the laptop is fixe-IP; that would include pita, the laptop). That simple copy does not get overwritten during use, so, all is well that ends (and I usually do not edit /etc/resolv.conf, I just leave the HghesNet DNS servers as the active ones if they're working.

Thanks for the interest.

Hope this helps some.

Thnx for your answer.

lazydog · 11-03-2016, 07:25 AM

Quote:

Originally Posted by jpollard

Actually, you could run your own caching server...

This isn't going to help you much unless you can change the TTL of the records. Most DNS records have a TTL of 1 day.

fanoflq · 11-03-2016, 08:39 AM

@tronayne:

Quote:

if DHCP rears its ugly head, is a simple copy to /etc/resolv.conf.

How do you determine if DHCP rears its ugly head?
DHCP is always in your router.
So it is always there. No?

jpollard · 11-03-2016, 09:52 AM

You can always change the default configuration of dhclient (usually /etc/dhclient.conf) to preserve the original content - that way you can "prepend" the wireless (since that will be the default) to the resolv.conf file, and will remove it when it stops - and your original reference will continue to be tried if the first entry fails.

tronayne · 11-03-2016, 12:40 PM

Quote:

Originally Posted by fanoflq

@tronayne:

How do you determine if DHCP rears its ugly head?
DHCP is always in your router.
So it is always there. No?

Yup, sure is in the router, but all my internal systems are fixed-IP and it doesn't bother me.

The sole exception is pita the laptop. Normally pita is connected via Ethernet to a router port. WICD is installed on pita and, when the Ethernet cable is in use it (WICD) doesn't do anything to /etc/resolv.conf but, when remote where wi-fi is the choice, DCHP takes over and causes /etc/resolv.conf to be overwritten (with no DNS address, thank you very much). Thus the back up copy of /etc/resolv.con and all is then well with the world: there is DNS service, so simple, so painless.

I have never been able to figure out just why that happens (I've tried pretty much everything to shut that off in whatever configuration file there is, no joy in Mudville).

I don't like network manager (it's a pain using fixed-IP that I don't want to deal with) and I'm perfectly happy to simply copy resolv.conf.bak over the rewritten file and be done with it -- pita is the only device on my LAN that will ever use wi-fi (I have no intention of every doing anything with IOT, do not go sit on the couch with the laptop in hand or any of that kind of stuff -- I have DirecTV and I will only connect it with Ethernet (and not often). pita is the only piece of equipment I have that ever uses DHCP directly and it's no problem to not have to deal with it.

Hope this helps some.