[PLUG] resolve.conf file

[Carlos Konstanski]

On Sun, 27 Dec 2009, Carlos Konstanski wrote:

> Date: Sun, 27 Dec 2009 11:39:24 -0700 (MST)
> From: Carlos Konstanski <ckonstanski at pippiandcarlos.com>
> Reply-To: "General Linux/UNIX discussion and help;	civil and on-topic"
>     <plug at lists.pdxlinux.org>
> To: "General Linux/UNIX discussion and help;	civil and on-topic"
>     <plug at lists.pdxlinux.org>
> Subject: Re: [PLUG] resolve.conf file
> 
> On Sun, 27 Dec 2009, Denis Heidtmann wrote:
>
>> Date: Sun, 27 Dec 2009 10:10:59 -0800
>> From: Denis Heidtmann <denis.heidtmann at gmail.com>
>> Reply-To: "General Linux/UNIX discussion and help;	civil and on-topic"
>>     <plug at lists.pdxlinux.org>
>> To: "General Linux/UNIX discussion and help,	civil and on-topic"
>>     <plug at lists.pdxlinux.org>
>> Subject: [PLUG] resolve.conf file
>>
>> I mentioned earlier that I was having trouble with a new dsl modem's
>> behavior as a dns server.  That has been resolved by avoiding dhcp.
>> This was accomplished with the help of a visiting geek (my son).
>> Resolveconf was installed; dns addresses set statically,
>>
>> As best as I can determine, everything is working fine.  But I seek
>> some understanding.  The resolv.conf contains some entries which make
>> no sense to me.  The visiting geek is no longer interested in these
>> questions, as it is no longer broken.  So I appeal to you.
>>
>> resolv.conf:
>>
>> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
>> #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
>> nameserver 192.168.0.1
>> nameserver 69.64.224.67
>> nameserver 69.64.224.66
>> search domain.actdsltmp
>>
>> I expect that the nameserver 192.168.0.1 entry is left over from
>> earlier dhcp responses.  (Visiting geek's Debian machine has only the
>> two valid nameserver entries in his file--he had not run a dhcp
>> client.)  Why does it persist in this file? And why does it not break
>> dns searches occasionally?  If I run dig repeatedly, only the
>> 69.64.224.67 address seems to get used.  If I force use of
>> 192.168.0.1, it fails, as expected.
>>
>> What does "search domain.actdsltmp" do?  Is domain.actdsltmp a valid name?
>>
>> Should I attempt to clean up this file?  If I should, how might that be done?
>>
>> Thanks for any education you can throw my way.
>>
>> -Denis
>
> 192.168.0.1 is most likely the IP address of your DSL router. I never
> used resolvconf, but if it's writing this file, then I'll bet that
> there is some sort of DNS server running on the router. Run the
> following command from a root shell (it will take a long time to run):
>
>   nmap -sU 192.168.0.1
>
> If you see UDP port 53 listed as open, then there is a DNS server
> running on the router. (If you see port 68, that's the DHCP server.)
> If this is true, it would be in your best interests to get it working
> properly, and use it instead of going directly to the ISP DNS
> servers. The local DNS server should be doing lookups on behalf of all
> users on your LAN, and caching the results for faster speed and less
> internet chatter.
>
> The "search" line is for when you attempt to resolve a
> non-fully-qualified hostname. For instance, my local domain is
> pippiandcarlos.com, and this is reflected in my resolv.conf file as
> "search pippiandcarlos.com". If I try to "ping ns", it will be
> converted to "ping ns.pippiandcarlos.com".
>
> I hate to be a party pooper, but I still feel that using resolvconf
> and static IPs is a bandaid that will continue to peel off when
> wet. The right thing to do is to get your own DNS and DHCP servers
> (the ones on the DSL router) working properly. Of course these DSL
> modems are notoriously crappy, and it is quite possible that fiddling
> with its configuration will have no effect. That's why I use cable and
> my own linux box as a router/firewall. Cable modems do not contain
> router/firewalls; they simply pass the connection through. The last
> DSL modem I had was an Actiontek which did not respond to any of my
> attempts to configure it. Qwest refused to replace it. They told me I
> could buy my own. Customer exits stage.
>
> Carlos

Correction: DHCP is on UDP port 67, not 68.

Carlos