Re: Can't find the DNS Servers

[David Wright]

On Fri 06 Oct 2017 at 09:03:05 (-0400), Greg Wooledge wrote:
> On Thu, Oct 05, 2017 at 08:35:22PM -0500, David Wright wrote:
> > On Thu 05 Oct 2017 at 08:55:33 (-0400), Greg Wooledge wrote:
> > > On Wed, Oct 04, 2017 at 07:23:51PM -0500, David Wright wrote:
> > > > Well, thank you. But this doesn't explain the paragraph above my 
> > > > comment.
> > > > I'm just trying to understand the suggestions being made by more
> > > > experienced folk here, like Reco and Greg.
> > > 
> > > My rationale is that having access to the Internet allows you to look up
> > > the answers to your problems, allows you to install missing software, etc.
> > > Being able to ping barney from fred on your LAN is pretty unimportant
> > > for most problem resolutions, compared to being able to ask Google "how
> > > do I set up NAT on Debian stretch", or whatever issue you're currently
> > > trying to solve.
> > 
> > I had assumed that the OP still had internet access from their other
> > machines.
> 
> Which is fine for simply asking questions and reading answers, but then
> if you need to apt-get install something, you're kinda screwed.

USB stick (aka sneakernet).

Cheers,
David.

Re: Can't find the DNS Servers

[David Wright]

On Fri 06 Oct 2017 at 01:22:18 (-0400), Gene Heskett wrote:
> On Thursday 05 October 2017 22:56:33 David Wright wrote:

> > One advantage of Powerlines is that they aren't bothered by
> > microwaves which knock out nearby 2GHz devices.
> 
> As in cooking microwaves? If its leaking that badly, have it serviced by 
> someone with a leakage measuring apparatus. Or replace it. That level of 
> leakage is sick bird on this side of the pond. I've checked and 
> rechecked the $100, 1kw model I got from wallies to take on the road 
> when I was out doing consultancy things after I retired for a few years, 
> in my kitchen now and can't find it with that meter. 15+ years old now, 
> I've had to replace some of the interlock microswitches, but 30 seconds 
> for a cuppa is still too hot. Sagging doors are the usual suspects.
> 
> Here we have to leak test our broadcast transmitters and be able to 
> certify they have a leakage field that is less than 5 milliwatts per CC 
> of human flesh exposed or we cannot renew our license.

I think your fears are misplaced and here's why:

5mW/cm² at 5cm is of course the maximum allowed by µwave ovens
once they're sold (1mW at the point of sale). Even at 5m, that
would still be 0.5µW/cm² given an air path, which is what there
is towards both laptop and TV.

The FCC maximum power density for general exposure is about
the same, so that gives an approximate value for the maximum
signal strength at the router and the laptops/rokus when
transmitting. But then we have to add in (or rather subtract)
the effects of (a) the three walls and two floor trusses
along with all their accessories plus the services and ducts
contained in them, which lie between said devices and the
router, (b) the fact that information has to be extracted
from the carrier signal, and (c) the router has to be able
to sort out the competing signals it is receiving from all
the sources in the kitchen.

Another factor that's probably difficult to estimate is
how much the computer devices have attenuated their signal
strengths (on the basis of reasonable reception) when the
µwave suddenly comes on. Do the devices retrain to the new
conditions? How long does that take? Is that why the TV
sometimes comes back? This last is complicated because the
buffering done by a roku varies by channel, programme
material, how far into a programme segment since the last
commercial, etc etc. Plenty of imponderables.

Cheers,
David.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Thu, Oct 05, 2017 at 08:35:22PM -0500, David Wright wrote:
> On Thu 05 Oct 2017 at 08:55:33 (-0400), Greg Wooledge wrote:
> > On Wed, Oct 04, 2017 at 07:23:51PM -0500, David Wright wrote:
> > > Well, thank you. But this doesn't explain the paragraph above my comment.
> > > I'm just trying to understand the suggestions being made by more
> > > experienced folk here, like Reco and Greg.
> > 
> > My rationale is that having access to the Internet allows you to look up
> > the answers to your problems, allows you to install missing software, etc.
> > Being able to ping barney from fred on your LAN is pretty unimportant
> > for most problem resolutions, compared to being able to ask Google "how
> > do I set up NAT on Debian stretch", or whatever issue you're currently
> > trying to solve.
> 
> I had assumed that the OP still had internet access from their other
> machines.

Which is fine for simply asking questions and reading answers, but then
if you need to apt-get install something, you're kinda screwed.

Re: Can't find the DNS Servers

[Gene Heskett]

On Thursday 05 October 2017 22:56:33 David Wright wrote:

> On Wed 04 Oct 2017 at 21:56:13 (-0400), Gene Heskett wrote:
> > On Wednesday 04 October 2017 20:23:51 David Wright wrote:
> > > On Wed 04 Oct 2017 at 18:14:12 (-0400), Gene Heskett wrote:
> > > > On Wednesday 04 October 2017 14:35:25 David Wright wrote:
> > > > > As I just posted, I thought the OP was already using a DNS
> > > > > server in the Actiontec router. (I don't have that choice.)
> > > >
> > > > Why not David?
> > >
> > > Because I have a "plastic" router with a server for DHCP but not
> > > DNS.
> > >
> > > > Get one that has enough memory to be reflashed with
> > > > dd-wrt, which will have that feature, and since its .de sourced,
> > > > not at all likely to have any back doors for the 3 letter
> > > > agencies.
> > >
> > > But why would I buy a wireless router that you don't trust enough
> > > to have its wireless turned on?
> >
> > A, I don't have it bridged to my network, so the wifi in the buffalo
> > can't get into me, only to the internet but that hasn't stopped an
> > enterprising neighbor from achieving a wpsk login and watching 80
> > gigs of whatever a month, so the radio remains turned off until one
> > of my boys drives in from Nebraska or Kansas, and wants his
> > smartphone to be able to access his email or whatever.  Thats just
> > common sense. Security, and universal access for critter phones do
> > not seem to play in the same arena. So the ultimate defense is the
> > wifi's power switch.
>
> I don't know what wpsk is. 

Probably a typu. Whatever, I had setup a passphrase that was the first 
chapter of a novel, and their gear had zero trouble kicking in the door

> Here I use WPA2-PSK(AES) which seems 
> to be secure enough. Our household couldn't function without
> wifi which is why we bought a wifi router.
>
> > I assume that same neighbor found the radio in an r-pi-3b thats been
> > running one of my cnc'd lathes for about 8 months, got a local
> > address from the dd-wrt dhcpd server, and which a jessie install
> > enabled w/o asking me, but that traffic I can see on the gkrellm
> > tallies, so that got powered down the next day.
> >
> > And B,C,D,E & F: security.
>
> I have no idea what that radio would be running. When I typed the
> above into google, the one project I looked at was only running
> WPA-PSK(TKIP). That's hackable, isn't it?

From my experience, yes.
>
> > > If we spend money here, it'll be for a repeater and/or more
> > > homeplug-style devices.
> >
> > A wifi repeater?  You can drive an 88,000 lb load of cold swinging
> > beef thru that security hole.  Homeplug-style I assume is some sort
> > of a powerline carried network?, x10 on an overdose of bandwidth
> > steroids? Explain plz if you've the time.
>
> Until recently, our house was serviced by two meters: the new one
> which comes underground to the new part, the old one which came
> overhead from the easement (where you'd normally expect a back alley)
> from a different street. The router sat in the old part (where the
> Cox cable comes in from the same pole as the old overhead power),
> and we used it from the new part, with very low signal strengths.
>
> Now we've connected the giant cable between the two breaker boxes
> and removed the old meter, we can use Powerline 1200s to link the
> modem (old part) to router (new part, where we are). Once we've
> remodelled the old part and start using it more, we could use
> more Powerlines¹ for static things like TV, but will probably
> need wifi there as well.
>
> One advantage of Powerlines is that they aren't bothered by
> microwaves which knock out nearby 2GHz devices.

As in cooking microwaves? If its leaking that badly, have it serviced by 
someone with a leakage measuring apparatus. Or replace it. That level of 
leakage is sick bird on this side of the pond. I've checked and 
rechecked the $100, 1kw model I got from wallies to take on the road 
when I was out doing consultancy things after I retired for a few years, 
in my kitchen now and can't find it with that meter. 15+ years old now, 
I've had to replace some of the interlock microswitches, but 30 seconds 
for a cuppa is still too hot. Sagging doors are the usual suspects.

Here we have to leak test our broadcast transmitters and be able to 
certify they have a leakage field that is less than 5 milliwatts per CC 
of human flesh exposed or we cannot renew our license.  Thats actually 
an easily detected level but must be measured with an omni-directional 
antenna.  Only one such device is available, and they rent it to us at 
$275/day.

Yeah, I'm actually a retired broadcast engineer.  What used to be a 1st 
phone, and CET cards in my card case. ;-)

I recall having to send the meter on to another tv station about 110 
miles south of us after I'd logged the measurements from our 50+ yo 35KW 
GE box, and he was curious and had it running when he walked into the 
stations lunch room while someone was warming their dinner, and it 
pegged 

Re: Can't find the DNS Servers

[David Wright]

On Wed 04 Oct 2017 at 21:56:13 (-0400), Gene Heskett wrote:
> On Wednesday 04 October 2017 20:23:51 David Wright wrote:
> 
> > On Wed 04 Oct 2017 at 18:14:12 (-0400), Gene Heskett wrote:
> > > On Wednesday 04 October 2017 14:35:25 David Wright wrote:

> > > > As I just posted, I thought the OP was already using a DNS server
> > > > in the Actiontec router. (I don't have that choice.)
> > >
> > > Why not David?
> >
> > Because I have a "plastic" router with a server for DHCP but not DNS.
> >
> > > Get one that has enough memory to be reflashed with
> > > dd-wrt, which will have that feature, and since its .de sourced, not
> > > at all likely to have any back doors for the 3 letter agencies.
> >
> > But why would I buy a wireless router that you don't trust enough
> > to have its wireless turned on?
> >
> A, I don't have it bridged to my network, so the wifi in the buffalo 
> can't get into me, only to the internet but that hasn't stopped an 
> enterprising neighbor from achieving a wpsk login and watching 80 gigs 
> of whatever a month, so the radio remains turned off until one of my 
> boys drives in from Nebraska or Kansas, and wants his smartphone to be 
> able to access his email or whatever.  Thats just common sense. 
> Security, and universal access for critter phones do not seem to play in 
> the same arena. So the ultimate defense is the wifi's power switch.

I don't know what wpsk is. Here I use WPA2-PSK(AES) which seems
to be secure enough. Our household couldn't function without
wifi which is why we bought a wifi router.

> I assume that same neighbor found the radio in an r-pi-3b thats been 
> running one of my cnc'd lathes for about 8 months, got a local address 
> from the dd-wrt dhcpd server, and which a jessie install enabled w/o 
> asking me, but that traffic I can see on the gkrellm tallies, so that 
> got powered down the next day.
> 
> And B,C,D,E & F: security.

I have no idea what that radio would be running. When I typed the
above into google, the one project I looked at was only running
WPA-PSK(TKIP). That's hackable, isn't it?

> > If we spend money here, it'll be for a repeater and/or more
> > homeplug-style devices.
> 
> A wifi repeater?  You can drive an 88,000 lb load of cold swinging beef 
> thru that security hole.  Homeplug-style I assume is some sort of a 
> powerline carried network?, x10 on an overdose of bandwidth steroids?  
> Explain plz if you've the time.

Until recently, our house was serviced by two meters: the new one
which comes underground to the new part, the old one which came
overhead from the easement (where you'd normally expect a back alley)
from a different street. The router sat in the old part (where the
Cox cable comes in from the same pole as the old overhead power),
and we used it from the new part, with very low signal strengths.

Now we've connected the giant cable between the two breaker boxes
and removed the old meter, we can use Powerline 1200s to link the
modem (old part) to router (new part, where we are). Once we've
remodelled the old part and start using it more, we could use
more Powerlines¹ for static things like TV, but will probably
need wifi there as well.

One advantage of Powerlines is that they aren't bothered by
microwaves which knock out nearby 2GHz devices. 5GHz isn't
bothered by the microwaves, but this part of the house seems
rather solidly built and I'm disappointed by the 5GHz performance
here compared with our previous house. By the time we've wrecked
the inside of the old part, the more open layout (the "reception
rooms" in UK parlance) might suit 5GHz a bit better.

¹We'll have to change the whole topology of course, because at the
moment the pair of Powerlines are carrying the (unshareable) WAN
side of the router rather than the LAN side.

Cheers,
David.

Re: Can't find the DNS Servers

[David Wright]

On Thu 05 Oct 2017 at 08:55:33 (-0400), Greg Wooledge wrote:
> On Wed, Oct 04, 2017 at 07:23:51PM -0500, David Wright wrote:
> > Well, thank you. But this doesn't explain the paragraph above my comment.
> > I'm just trying to understand the suggestions being made by more
> > experienced folk here, like Reco and Greg.
> 
> My rationale is that having access to the Internet allows you to look up
> the answers to your problems, allows you to install missing software, etc.
> Being able to ping barney from fred on your LAN is pretty unimportant
> for most problem resolutions, compared to being able to ask Google "how
> do I set up NAT on Debian stretch", or whatever issue you're currently
> trying to solve.

I had assumed that the OP still had internet access from their other
machines.

> As far as /etc/hosts vs. setting up an internal DNS server, most home
> LANs are probably small enough that I would simply use /etc/hosts.
> Things may change if you live in a mansion with a staff, or you're the
> landlord for an apartment building, or something.  My cut-off point would
> probably be a dozen machines.  If there are more than a dozen machines,
> then I would consider setting up an internal DNS server for them.

I always think it odd that a router that issues hostnames and IP
addresses to hosts can't spit the same information out when given
a DNS query. But I've assumed that setting it up to do so would
involve no work; the work is in typing the information into the
DHCP pages.

So if you have a DNS-serving router, it would seem defeatest to
then have to maintain /etc/hosts files, and it just hides the
problem which, thankfully, has now been found.

Cheers,
David.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Wed, Oct 04, 2017 at 07:23:51PM -0500, David Wright wrote:
> Well, thank you. But this doesn't explain the paragraph above my comment.
> I'm just trying to understand the suggestions being made by more
> experienced folk here, like Reco and Greg.

My rationale is that having access to the Internet allows you to look up
the answers to your problems, allows you to install missing software, etc.
Being able to ping barney from fred on your LAN is pretty unimportant
for most problem resolutions, compared to being able to ask Google "how
do I set up NAT on Debian stretch", or whatever issue you're currently
trying to solve.

As far as /etc/hosts vs. setting up an internal DNS server, most home
LANs are probably small enough that I would simply use /etc/hosts.
Things may change if you live in a mansion with a staff, or you're the
landlord for an apartment building, or something.  My cut-off point would
probably be a dozen machines.  If there are more than a dozen machines,
then I would consider setting up an internal DNS server for them.

Re: Can't find the DNS Servers

[Reco]

On Wed, Oct 04, 2017 at 03:57:33PM -0700, Gary Roach wrote:
> On 10/04/2017 11:13 AM, Reco wrote:
> > On Wed, Oct 04, 2017 at 02:08:17PM -0400, Michael Stone wrote:
> > > On Wed, Oct 04, 2017 at 08:59:46PM +0300, Reco wrote:
> > > > On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> > > > > On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > > > > > A correct way to fix this is to "persuade" your DHCP server not to
> > > > > > provide DNS information.
> > > > > > Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> > > > > > forwarder DNS.
> > > > > > Since it's unnaturally complex to do so in a consumer-grade 
> > > > > > routers, a
> > > > > > hack is in order.
> > > > > 
> > > > > But won't that send local host lookups to google which won't have a 
> > > > > clue?
> > > > 
> > > > Why won't it have a clue?
> > > 
> > > Because google doesn't know what names you use on your local network.
> > 
> > Once one starts using 8.8.8.8 - it will. Even it won't show it.
> > Friends don't let friends use Google resolvers.
> > A software that's using "Four Eights" by default was considered buggy in
> > Debian back in the day.
> > 
> > > To
> > > implement local lookups you need a name server which can selectively 
> > > either
> > > serve a local name or forward the request to an internet name server.
> > 
> > Avahi, anyone?
> > 
> > > That
> > > can't be done in resolv.conf, but can be done either centrally or locally
> > > via unbound or similar.
> > 
> > Or, /etc/hosts. For a simple household network how hard could it be?
> > 
> > Reco
> > 
> > 
> Rico,
> 
> I filled /etc/hosts and can get named service to my local network but can't
> get on to the internet. It's like something is blocking access to any
> nameservers.

The contents of /etc/nsswitch.conf, please.
The current contents of /etc/resolv.conf.

The output of (terminate it with Ctrl+C after 60 seconds):

tcpdump -nvi any udp port 53 or tcp port 53 or udp port 5353

While doing:

getent hosts go.dev

Reco

Re: Can't find the DNS Servers

[Gene Heskett]

On Wednesday 04 October 2017 20:23:51 David Wright wrote:

> On Wed 04 Oct 2017 at 18:14:12 (-0400), Gene Heskett wrote:
> > On Wednesday 04 October 2017 14:35:25 David Wright wrote:
> > > On Wed 04 Oct 2017 at 13:21:02 (-0400), Greg Wooledge wrote:
> > > > On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> > > > > On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > > > > > A correct way to fix this is to "persuade" your DHCP server
> > > > > > not to provide DNS information.
> > > > > > Even more correct way is to force your DNS-at-DHCP to use
> > > > > > 8.8.8.8 as forwarder DNS.
> > > > > > Since it's unnaturally complex to do so in a consumer-grade
> > > > > > routers, a hack is in order.
> > > > >
> > > > > But won't that send local host lookups to google which won't
> > > > > have a clue?
> > > >
> > > > Which problem are we attempting to solve, exactly?  I seem to
> > > > recall that the reported symptom was "I can't do apt-get
> > > > update", which means the priority is getting real Internet DNS
> > > > resolution working.
> > >
> > > "I can't even reach the other computers on my home network if I
> > > use their names. IP addresses work OK." as well.
> >
> > You probably could if you enter their addresses and names in
> > your /etc/hosts file, and you can run the identical /etc/hosts file
> > on every machine on your home network.
>
> Yes, I do that. The OP is presumably used to not having to do that.
>
> > If you have network-mangler installed and running, stop it and
> > remove it else you may have to make your /etc/resolv.conf into a
> > normal file, make the nameservers work, then chattr +i resolv.conf
> > to keep n-m from tearing down a working network.
> >
> > It should, if your router runs something like dnsmasq, be sufficient
> > to point the nameserver entry in your resolv.conf at the router,
> > which will, if its internal lookups fail, forward the dns request to
> > your ISP's dns servers. That adds about 60 milliseconds to the ping
> > time of some site never visited before.
>
> Yes, I do that. As stated below, there are no internal lookups,
> but the router has google nameservers configured in place of its
> downloading them from my ISP.
>
> > > > If there's a need to add local area network hosts, then *after*
> > > > the real Internet DNS is working, the OP can decide whether to
> > > > add LAN hosts to /etc/hosts on each machine, or to set up a LAN
> > > > DNS nameserver, and wrangle resolv.conf and/or DHCP to point to
> > > > it. (Many steps and details omitted here for simplicity's sake.)
> > >
> > > I'm obviously out of my league. I was under the impression that
> > > everyone set up networking by working outwards from the loopback
> > > interface to the universe, rather than the other way round.
> >
> > Basically that is how it works.
>
> Well, thank you. But this doesn't explain the paragraph above my
> comment. I'm just trying to understand the suggestions being made by
> more experienced folk here, like Reco and Greg.
>
> I suppose the main things I don't understand are:
> why set up the DNS to resolve externals' addresses before internals';
> why send LAN DNS queries out to 8.8.8.8 before consulting the LAN's
> own server; why, on a home network, set external servers (like
> 8.8.8.8) in all the hosts' resolv.conf if the router itself can pass
> queries to them. After all, if the router's not up, then those
> external servers are unreachable anyway.
>
> > > > Which way the OP *should* go depends mostly on how many LAN
> > > > hosts we're talking about.  Which way they *will* go... anyone's
> > > > guess.
> >
> > Your /etc/hosts file can have, IIRC, up to 253 ipv4 entries. And it
> > still is identical on all machines provided they all know their
> > assigned names.  Check that by running hostname w/o an argument. See
> > man hostname, ditto for domainname.
>
> Um, I'm not sure what you're remembering.
> $ wc /etc/hosts
>  13263  27599 402246 /etc/hosts
> $
> I think there are limits on line length/aliases.
>
> > > As I just posted, I thought the OP was already using a DNS server
> > > in the Actiontec router. (I don't have that choice.)
> >
> > Why not David?
>
> Because I have a "plastic" router with a server for DHCP but not DNS.
>
> > Get one that has enough memory to be reflashed with
> > dd-wrt, which will have that feature, and since its .de sourced, not
> > at all likely to have any back doors for the 3 letter agencies.
>
> But why would I buy a wireless router that you don't trust enough
> to have its wireless turned on?
>
A, I don't have it bridged to my network, so the wifi in the buffalo 
can't get into me, only to the internet but that hasn't stopped an 
enterprising neighbor from achieving a wpsk login and watching 80 gigs 
of whatever a month, so the radio remains turned off until one of my 
boys drives in from Nebraska or Kansas, and wants his smartphone to be 
able to access his email or whatever.  Thats just common sense. 
Security, and 

Re: Can't find the DNS Servers

[David Wright]

On Wed 04 Oct 2017 at 18:14:12 (-0400), Gene Heskett wrote:
> On Wednesday 04 October 2017 14:35:25 David Wright wrote:
> 
> > On Wed 04 Oct 2017 at 13:21:02 (-0400), Greg Wooledge wrote:
> > > On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> > > > On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > > > > A correct way to fix this is to "persuade" your DHCP server not
> > > > > to provide DNS information.
> > > > > Even more correct way is to force your DNS-at-DHCP to use
> > > > > 8.8.8.8 as forwarder DNS.
> > > > > Since it's unnaturally complex to do so in a consumer-grade
> > > > > routers, a hack is in order.
> > > >
> > > > But won't that send local host lookups to google which won't have
> > > > a clue?
> > >
> > > Which problem are we attempting to solve, exactly?  I seem to recall
> > > that the reported symptom was "I can't do apt-get update", which
> > > means the priority is getting real Internet DNS resolution working.
> >
> > "I can't even reach the other computers on my home network if I use
> > their names. IP addresses work OK." as well.
> >
> You probably could if you enter their addresses and names in 
> your /etc/hosts file, and you can run the identical /etc/hosts file on 
> every machine on your home network.

Yes, I do that. The OP is presumably used to not having to do that.

> If you have network-mangler installed and running, stop it and remove it 
> else you may have to make your /etc/resolv.conf into a normal file, make 
> the nameservers work, then chattr +i resolv.conf to keep n-m from 
> tearing down a working network.
> 
> It should, if your router runs something like dnsmasq, be sufficient to 
> point the nameserver entry in your resolv.conf at the router, which 
> will, if its internal lookups fail, forward the dns request to your 
> ISP's dns servers. That adds about 60 milliseconds to the ping time of 
> some site never visited before.

Yes, I do that. As stated below, there are no internal lookups,
but the router has google nameservers configured in place of its
downloading them from my ISP.

> > > If there's a need to add local area network hosts, then *after* the
> > > real Internet DNS is working, the OP can decide whether to add LAN
> > > hosts to /etc/hosts on each machine, or to set up a LAN DNS
> > > nameserver, and wrangle resolv.conf and/or DHCP to point to it. 
> > > (Many steps and details omitted here for simplicity's sake.)
> >
> > I'm obviously out of my league. I was under the impression that
> > everyone set up networking by working outwards from the loopback
> > interface to the universe, rather than the other way round.
> 
> Basically that is how it works.

Well, thank you. But this doesn't explain the paragraph above my comment.
I'm just trying to understand the suggestions being made by more
experienced folk here, like Reco and Greg.

I suppose the main things I don't understand are:
why set up the DNS to resolve externals' addresses before internals';
why send LAN DNS queries out to 8.8.8.8 before consulting the LAN's
own server; why, on a home network, set external servers (like
8.8.8.8) in all the hosts' resolv.conf if the router itself can pass
queries to them. After all, if the router's not up, then those
external servers are unreachable anyway.

> > > Which way the OP *should* go depends mostly on how many LAN hosts
> > > we're talking about.  Which way they *will* go... anyone's guess.
> 
> Your /etc/hosts file can have, IIRC, up to 253 ipv4 entries. And it still 
> is identical on all machines provided they all know their assigned 
> names.  Check that by running hostname w/o an argument. See man 
> hostname, ditto for domainname.

Um, I'm not sure what you're remembering.
$ wc /etc/hosts
 13263  27599 402246 /etc/hosts
$ 
I think there are limits on line length/aliases.

> > As I just posted, I thought the OP was already using a DNS server in
> > the Actiontec router. (I don't have that choice.)
> >
> Why not David?

Because I have a "plastic" router with a server for DHCP but not DNS.

> Get one that has enough memory to be reflashed with 
> dd-wrt, which will have that feature, and since its .de sourced, not at 
> all likely to have any back doors for the 3 letter agencies.

But why would I buy a wireless router that you don't trust enough
to have its wireless turned on?

If we spend money here, it'll be for a repeater and/or more
homeplug-style devices.

> Most routers in the $70+ category can do that. In way over a decade, only 
> one person has come thru dd-wrt and I had to give him all the usernames 
> and passwd's to do so. I needed his expertise at the time.
> 
> Buffalo sells several with dd-wrt already installed, but their branding 
> covered up a needed section of the setup, so I had to go get the real 
> thing from the dd-wrt site & install it.  Shrug.

Cheers,
David.

Re: Can't find the DNS Servers

[Gary Roach]

On 10/04/2017 11:13 AM, Reco wrote:

On Wed, Oct 04, 2017 at 02:08:17PM -0400, Michael Stone wrote:

On Wed, Oct 04, 2017 at 08:59:46PM +0300, Reco wrote:

On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:

On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:

A correct way to fix this is to "persuade" your DHCP server not to
provide DNS information.
Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
forwarder DNS.
Since it's unnaturally complex to do so in a consumer-grade routers, a
hack is in order.


But won't that send local host lookups to google which won't have a clue?


Why won't it have a clue?


Because google doesn't know what names you use on your local network.


Once one starts using 8.8.8.8 - it will. Even it won't show it.
Friends don't let friends use Google resolvers.
A software that's using "Four Eights" by default was considered buggy in
Debian back in the day.


To
implement local lookups you need a name server which can selectively either
serve a local name or forward the request to an internet name server.


Avahi, anyone?


That
can't be done in resolv.conf, but can be done either centrally or locally
via unbound or similar.


Or, /etc/hosts. For a simple household network how hard could it be?

Reco



Rico,

I filled /etc/hosts and can get named service to my local network but 
can't get on to the internet. It's like something is blocking access to 
any nameservers.


Gary R.

Re: Can't find the DNS Servers

[Gene Heskett]

On Wednesday 04 October 2017 14:35:25 David Wright wrote:

> On Wed 04 Oct 2017 at 13:21:02 (-0400), Greg Wooledge wrote:
> > On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> > > On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > > > A correct way to fix this is to "persuade" your DHCP server not
> > > > to provide DNS information.
> > > > Even more correct way is to force your DNS-at-DHCP to use
> > > > 8.8.8.8 as forwarder DNS.
> > > > Since it's unnaturally complex to do so in a consumer-grade
> > > > routers, a hack is in order.
> > >
> > > But won't that send local host lookups to google which won't have
> > > a clue?
> >
> > Which problem are we attempting to solve, exactly?  I seem to recall
> > that the reported symptom was "I can't do apt-get update", which
> > means the priority is getting real Internet DNS resolution working.
>
> "I can't even reach the other computers on my home network if I use
> their names. IP addresses work OK." as well.
>
You probably could if you enter their addresses and names in 
your /etc/hosts file, and you can run the identical /etc/hosts file on 
every machine on your home network. That /etc/hosts file will resemble 
this one:

oot@coyote:~# cat /etc/hosts
127.0.0.1 localhost
192.168.xx.1router.coyote.den   router
192.168.xx.2rock64Sheldon.coyote.denrock64  rock64Sheldon
192.168.xx.3coyote.coyote.den   coyote
192.168.xx.4shop.coyote.den shop
192.168.xx.5lathe.coyote.denlathe
192.168.xx.6lappy.coyote.denlappy
192.168.xx.7sheldon.coyote.den  sheldon
192.168.xx.8raspberrypi.coyote.den  raspi
192.168.xx.9odroid64.coyote.den odroid64
192.168.xx.10   GO704.coyote.denGO704
192.168.xx.12   picnc.coyote.denpicnc
192.168.xx.21   scanner.coyote.den  scanner
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Replace the xx.#, the FQDN names and aliases, with yours. And note too 
that you can have more than 1 alias as I show for xx.2 above.

If you have network-mangler installed and running, stop it and remove it 
else you may have to make your /etc/resolv.conf into a normal file, make 
the nameservers work, then chattr +i resolv.conf to keep n-m from 
tearing down a working network.

It should, if your router runs something like dnsmasq, be sufficient to 
point the nameserver entry in your resolv.conf at the router, which 
will, if its internal lookups fail, forward the dns request to your 
ISP's dns servers. That adds about 60 milliseconds to the ping time of 
some site never visited before.


> > If there's a need to add local area network hosts, then *after* the
> > real Internet DNS is working, the OP can decide whether to add LAN
> > hosts to /etc/hosts on each machine, or to set up a LAN DNS
> > nameserver, and wrangle resolv.conf and/or DHCP to point to it. 
> > (Many steps and details omitted here for simplicity's sake.)
>
> I'm obviously out of my league. I was under the impression that
> everyone set up networking by working outwards from the loopback
> interface to the universe, rather than the other way round.

Basically that is how it works.
>
> > Which way the OP *should* go depends mostly on how many LAN hosts
> > we're talking about.  Which way they *will* go... anyone's guess.

Your /etc/hosts file can have, IIRC, up to 253 ipv4 entries. And it still 
is identical on all machines provided they all know their assigned 
names.  Check that by running hostname w/o an argument. See man 
hostname, ditto for domainname.

> As I just posted, I thought the OP was already using a DNS server in
> the Actiontec router. (I don't have that choice.)
>
Why not David? Get one that has enough memory to be reflashed with 
dd-wrt, which will have that feature, and since its .de sourced, not at 
all likely to have any back doors for the 3 letter agencies.

Most routers in the $70+ category can do that. In way over a decade, only 
one person has come thru dd-wrt and I had to give him all the usernames 
and passwd's to do so. I needed his expertise at the time.

Buffalo sells several with dd-wrt already installed, but their branding 
covered up a needed section of the setup, so I had to go get the real 
thing from the dd-wrt site & install it.  Shrug.

> Cheers,
> David.

Cheers David, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[Reco]

Hi.

On Wed, Oct 04, 2017 at 12:54:46PM -0700, Gary Roach wrote:
> On 10/04/2017 10:59 AM, Reco wrote:
> > Hi.
> > 
> > On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> > > On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > > > Hi.
> > > > 
> > > > On Tue, Oct 03, 2017 at 01:30:11PM -0700, Gary Roach wrote:
> > > > > OK Rico> I followed your instructions and still have the same problem.
> > > > > Attached are the new files. Already installed were isc-dhcp-client and
> > > > > resolvconf. You are right about the br1 entry not being needed. the 
> > > > > virtual
> > > > > machine works fine without it.
> > > > 
> > > > So, what we have now is a definite improvement over the last time, but
> > > > some twists are needed.
> > > > 
> > > > While "dns-nameserver" stanzas are working now, your DHCP server also
> > > > advertises its own:
> > > > 
> > > > > # 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.1.1
> > > > > nameserver 8.8.8.8
> > > > > nameserver 8.8.4.4
> > > > 
> > > > A correct way to fix this is to "persuade" your DHCP server not to
> > > > provide DNS information.
> > > > Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> > > > forwarder DNS.
> > > > Since it's unnaturally complex to do so in a consumer-grade routers, a
> > > > hack is in order.
> I made the changes to dhclient you suggested. There was no change in the
> problem. Attached is the new version of dhclient.
> 
> Next?

The contents of /etc/nsswitch.conf, please.
The current contents of /etc/resolv.conf.

The output of (terminate it with Ctrl+C after 60 seconds):

tcpdump -nvi any udp port 53 or tcp port 53 or udp port 5353

While doing:

getent hosts go.dev

Reco

Re: Can't find the DNS Servers

[Gary Roach]

On 10/04/2017 10:59 AM, Reco wrote:

Hi.

On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:

On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:

Hi.

On Tue, Oct 03, 2017 at 01:30:11PM -0700, Gary Roach wrote:

OK Rico> I followed your instructions and still have the same problem.
Attached are the new files. Already installed were isc-dhcp-client and
resolvconf. You are right about the br1 entry not being needed. the virtual
machine works fine without it.


So, what we have now is a definite improvement over the last time, but
some twists are needed.

While "dns-nameserver" stanzas are working now, your DHCP server also
advertises its own:


# 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.1.1
nameserver 8.8.8.8
nameserver 8.8.4.4


A correct way to fix this is to "persuade" your DHCP server not to
provide DNS information.
Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
forwarder DNS.
Since it's unnaturally complex to do so in a consumer-grade routers, a
hack is in order.


But won't that send local host lookups to google which won't have a clue?


Why won't it have a clue?

"Four eights" is a huge pool of public resolvers. "Free" to use (in a
Google sense of a word).

An unnamed consumer-grade router will happily pass DNS requests to
anywhere. Unless it's been tinkered with, which is outside of scope of
this problem.

ISP, of course can:

1) Pass DNS request along, as good ISP should.

2) Route DNS queries to *their* DNS servers. Whenever IPS is abided by
law to do so or merely tries to hijack NXDOMAIN answers to raise some
profit is hardly relevant to the issue.

3) Block DNS requests unless it is going to *their* DNS. Best thing that
can be done about this kind of ISP is contract termination.

Reco


I made the changes to dhclient you suggested. There was no change in the 
problem. Attached is the new version of dhclient.


Next?

Gary R
# Configuration file for /sbin/dhclient.
#
# This is a sample configuration file for dhclient. See dhclient.conf's
#   man page for more information about the syntax of this file
#   and a more comprehensive list of the parameters understood by
#   dhclient.
#
# Normally, if the DHCP server provides reasonable information and does
#   not leave anything out (like the domain name, for example), then
#   few changes must be made to this file, if any.
#

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
domain-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;

#send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
#send dhcp-lease-time 3600;
#supersede domain-name "fugue.com home.vix.com";
#prepend domain-name-servers 127.0.0.1;
#require subnet-mask, domain-name-servers;
#timeout 60;
#retry 60;
#reboot 10;
#select-timeout 5;
#initial-interval 2;
#script "/sbin/dhclient-script";
#media "-link0 -link1 -link2", "link0 link1";
#reject 192.33.137.209;

#alias {
#  interface "eth0";
#  fixed-address 192.5.5.213;
#  option subnet-mask 255.255.255.255;
#}

#lease {
#  interface "eth0";
#  fixed-address 192.33.137.200;
#  medium "link0 link1";
#  option host-name "andare.swiftmedia.com";
#  option subnet-mask 255.255.255.0;
#  option broadcast-address 192.33.137.255;
#  option routers 192.33.137.250;
#  option domain-name-servers 127.0.0.1;
#  renew 2 2000/1/12 00:00:01;
#  rebind 2 2000/1/12 00:00:01;
#  expire 2 2000/1/12 00:00:01;
#}

Re: Can't find the DNS Servers

[Reco]

On Wed, Oct 04, 2017 at 01:30:21PM -0500, David Wright wrote:
> On Wed 04 Oct 2017 at 21:13:51 (+0300), Reco wrote:
> > On Wed, Oct 04, 2017 at 02:08:17PM -0400, Michael Stone wrote:
> > > On Wed, Oct 04, 2017 at 08:59:46PM +0300, Reco wrote:
> > > > On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> > > > > On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > > > > > A correct way to fix this is to "persuade" your DHCP server not to
> > > > > > provide DNS information.
> > > > > > Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> > > > > > forwarder DNS.
> > > > > > Since it's unnaturally complex to do so in a consumer-grade 
> > > > > > routers, a
> > > > > > hack is in order.
> > > > > 
> > > > > But won't that send local host lookups to google which won't have a 
> > > > > clue?
> > > > 
> > > > Why won't it have a clue?
> > > 
> > > Because google doesn't know what names you use on your local network.
> > 
> > Once one starts using 8.8.8.8 - it will. Even it won't show it.
> > Friends don't let friends use Google resolvers.
> > A software that's using "Four Eights" by default was considered buggy in
> > Debian back in the day.
> 
> Can I just check that we're talking about the same thing? Are you
> saying that if I ask 8.8.8.8 for the IP address of wasp (that's its
> "FQDN") it will reply with 192.168.1.13?

No, it should answer NXDOMAIN.
But Google will remember that you have a host with this name.
It may even advertise you a wasp repellent one day.


> > > To
> > > implement local lookups you need a name server which can selectively 
> > > either
> > > serve a local name or forward the request to an internet name server.
> 
> Just to be clear, I'm using "local" in the everyday meaning, not in
> the sense of .local in whichever RFC it is.

Other than being a violation of RFC 6762 (and the thing Microsoft
suggests) that's probably OK.


> > > That
> > > can't be done in resolv.conf, but can be done either centrally or locally
> > > via unbound or similar.
> > 
> > Or, /etc/hosts. For a simple household network how hard could it be?
> 
> I was under the impression that the OP had a DNS-serving router which
> could perform that job successfully (a) before setting up qemu-kvm

"apt install qemu-kvm" could not lead to this result.
Even with "apt install libvirt-daemon-system" it's impossible.

Installing these packages *and* implementing a howto or two from random
Internet sites - that's definitely possible.


> and (b) still worked for whatever a qemu-kvm is but not for the
> actual ?host machine.

By default libvirt creates "virbr0" bridge and starts dnsmasq (if it's
installed) to serve DNS and DHCP requests coming from "domains" (aka
virtual machines). So yes, *some* DNS requests from inside virbr0 should
work.

Reco

Re: Can't find the DNS Servers

[David Wright]

On Wed 04 Oct 2017 at 13:21:02 (-0400), Greg Wooledge wrote:
> On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> > On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > > A correct way to fix this is to "persuade" your DHCP server not to
> > > provide DNS information.
> > > Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> > > forwarder DNS.
> > > Since it's unnaturally complex to do so in a consumer-grade routers, a
> > > hack is in order.
> > 
> > But won't that send local host lookups to google which won't have a clue?
> 
> Which problem are we attempting to solve, exactly?  I seem to recall
> that the reported symptom was "I can't do apt-get update", which means
> the priority is getting real Internet DNS resolution working.

"I can't even reach the other computers on my home network if I use
their names. IP addresses work OK." as well.

> If there's a need to add local area network hosts, then *after* the real
> Internet DNS is working, the OP can decide whether to add LAN hosts
> to /etc/hosts on each machine, or to set up a LAN DNS nameserver, and
> wrangle resolv.conf and/or DHCP to point to it.  (Many steps and details
> omitted here for simplicity's sake.)

I'm obviously out of my league. I was under the impression that
everyone set up networking by working outwards from the loopback
interface to the universe, rather than the other way round.

> Which way the OP *should* go depends mostly on how many LAN hosts we're
> talking about.  Which way they *will* go... anyone's guess.

As I just posted, I thought the OP was already using a DNS server in
the Actiontec router. (I don't have that choice.)

Cheers,
David.

Re: Can't find the DNS Servers

[David Wright]

On Wed 04 Oct 2017 at 21:13:51 (+0300), Reco wrote:
> On Wed, Oct 04, 2017 at 02:08:17PM -0400, Michael Stone wrote:
> > On Wed, Oct 04, 2017 at 08:59:46PM +0300, Reco wrote:
> > > On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> > > > On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > > > > A correct way to fix this is to "persuade" your DHCP server not to
> > > > > provide DNS information.
> > > > > Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> > > > > forwarder DNS.
> > > > > Since it's unnaturally complex to do so in a consumer-grade routers, a
> > > > > hack is in order.
> > > > 
> > > > But won't that send local host lookups to google which won't have a 
> > > > clue?
> > > 
> > > Why won't it have a clue?
> > 
> > Because google doesn't know what names you use on your local network.
> 
> Once one starts using 8.8.8.8 - it will. Even it won't show it.
> Friends don't let friends use Google resolvers.
> A software that's using "Four Eights" by default was considered buggy in
> Debian back in the day.

Can I just check that we're talking about the same thing? Are you
saying that if I ask 8.8.8.8 for the IP address of wasp (that's its
"FQDN") it will reply with 192.168.1.13?

> > To
> > implement local lookups you need a name server which can selectively either
> > serve a local name or forward the request to an internet name server.

Just to be clear, I'm using "local" in the everyday meaning, not in
the sense of .local in whichever RFC it is.

> > That
> > can't be done in resolv.conf, but can be done either centrally or locally
> > via unbound or similar.
> 
> Or, /etc/hosts. For a simple household network how hard could it be?

I was under the impression that the OP had a DNS-serving router which
could perform that job successfully (a) before setting up qemu-kvm
and (b) still worked for whatever a qemu-kvm is but not for the
actual ?host machine.

Cheers,
David.

Re: Can't find the DNS Servers

[Reco]

On Wed, Oct 04, 2017 at 02:08:17PM -0400, Michael Stone wrote:
> On Wed, Oct 04, 2017 at 08:59:46PM +0300, Reco wrote:
> > On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> > > On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > > > A correct way to fix this is to "persuade" your DHCP server not to
> > > > provide DNS information.
> > > > Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> > > > forwarder DNS.
> > > > Since it's unnaturally complex to do so in a consumer-grade routers, a
> > > > hack is in order.
> > > 
> > > But won't that send local host lookups to google which won't have a clue?
> > 
> > Why won't it have a clue?
> 
> Because google doesn't know what names you use on your local network.

Once one starts using 8.8.8.8 - it will. Even it won't show it.
Friends don't let friends use Google resolvers.
A software that's using "Four Eights" by default was considered buggy in
Debian back in the day.

> To
> implement local lookups you need a name server which can selectively either
> serve a local name or forward the request to an internet name server.

Avahi, anyone?

> That
> can't be done in resolv.conf, but can be done either centrally or locally
> via unbound or similar.

Or, /etc/hosts. For a simple household network how hard could it be?

Reco

Re: Can't find the DNS Servers

[Michael Stone]

On Wed, Oct 04, 2017 at 08:59:46PM +0300, Reco wrote:

On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:

On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> A correct way to fix this is to "persuade" your DHCP server not to
> provide DNS information.
> Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> forwarder DNS.
> Since it's unnaturally complex to do so in a consumer-grade routers, a
> hack is in order.

But won't that send local host lookups to google which won't have a clue?


Why won't it have a clue?


Because google doesn't know what names you use on your local network. To 
implement local lookups you need a name server which can selectively 
either serve a local name or forward the request to an internet name 
server. That can't be done in resolv.conf, but can be done either 
centrally or locally via unbound or similar. 


Mike Stone

Re: Can't find the DNS Servers

[Reco]

Hi.

On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > Hi.
> > 
> > On Tue, Oct 03, 2017 at 01:30:11PM -0700, Gary Roach wrote:
> > > OK Rico> I followed your instructions and still have the same problem.
> > > Attached are the new files. Already installed were isc-dhcp-client and
> > > resolvconf. You are right about the br1 entry not being needed. the 
> > > virtual
> > > machine works fine without it.
> > 
> > So, what we have now is a definite improvement over the last time, but
> > some twists are needed.
> > 
> > While "dns-nameserver" stanzas are working now, your DHCP server also
> > advertises its own:
> > 
> > > # 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.1.1
> > > nameserver 8.8.8.8
> > > nameserver 8.8.4.4
> > 
> > A correct way to fix this is to "persuade" your DHCP server not to
> > provide DNS information.
> > Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> > forwarder DNS.
> > Since it's unnaturally complex to do so in a consumer-grade routers, a
> > hack is in order.
> 
> But won't that send local host lookups to google which won't have a clue?

Why won't it have a clue?

"Four eights" is a huge pool of public resolvers. "Free" to use (in a
Google sense of a word).

An unnamed consumer-grade router will happily pass DNS requests to
anywhere. Unless it's been tinkered with, which is outside of scope of
this problem.

ISP, of course can:

1) Pass DNS request along, as good ISP should.

2) Route DNS queries to *their* DNS servers. Whenever IPS is abided by
law to do so or merely tries to hijack NXDOMAIN answers to raise some
profit is hardly relevant to the issue.

3) Block DNS requests unless it is going to *their* DNS. Best thing that
can be done about this kind of ISP is contract termination.

Reco

Re: Can't find the DNS Servers

[Greg Wooledge]

On Wed, Oct 04, 2017 at 11:59:04AM -0500, David Wright wrote:
> On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
> > A correct way to fix this is to "persuade" your DHCP server not to
> > provide DNS information.
> > Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> > forwarder DNS.
> > Since it's unnaturally complex to do so in a consumer-grade routers, a
> > hack is in order.
> 
> But won't that send local host lookups to google which won't have a clue?

Which problem are we attempting to solve, exactly?  I seem to recall
that the reported symptom was "I can't do apt-get update", which means
the priority is getting real Internet DNS resolution working.

If there's a need to add local area network hosts, then *after* the real
Internet DNS is working, the OP can decide whether to add LAN hosts
to /etc/hosts on each machine, or to set up a LAN DNS nameserver, and
wrangle resolv.conf and/or DHCP to point to it.  (Many steps and details
omitted here for simplicity's sake.)

Which way the OP *should* go depends mostly on how many LAN hosts we're
talking about.  Which way they *will* go... anyone's guess.

Re: Can't find the DNS Servers

[David Wright]

On Wed 04 Oct 2017 at 09:11:37 (+0300), Reco wrote:
>   Hi.
> 
> On Tue, Oct 03, 2017 at 01:30:11PM -0700, Gary Roach wrote:
> > OK Rico> I followed your instructions and still have the same problem.
> > Attached are the new files. Already installed were isc-dhcp-client and
> > resolvconf. You are right about the br1 entry not being needed. the virtual
> > machine works fine without it.
> 
> So, what we have now is a definite improvement over the last time, but
> some twists are needed.
> 
> While "dns-nameserver" stanzas are working now, your DHCP server also
> advertises its own:
> 
> > # 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.1.1
> > nameserver 8.8.8.8
> > nameserver 8.8.4.4
> 
> A correct way to fix this is to "persuade" your DHCP server not to
> provide DNS information.
> Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
> forwarder DNS.
> Since it's unnaturally complex to do so in a consumer-grade routers, a
> hack is in order.

But won't that send local host lookups to google which won't have a clue?

Cheers,
David.

Re: Can't find the DNS Servers

[David Wright]

On Wed 04 Oct 2017 at 08:38:10 (-0400), Greg Wooledge wrote:
> On Tue, Oct 03, 2017 at 04:47:35PM -0700, Gary Roach wrote:
> > Symptoms: Any package that needs access to the network sends an error
> > message indicating that it doesn't have access to the internet. Ping doesn't
> > work for names but does for ip addresses. All ip addresses both local and
> > global.
> 
> Show, don't tell.
[…]
> > In short, there doesn't seem to be any access to a name server. My believe
> > that my Actiontec router at 192.168.1.1 also acts as a name server.
> 
> In your diagnostic command-and-response session, be sure to include
> the results of your attempts to ping your nameserver by IP address,
> and of performing a DNS lookup using that nameserver.  See examples
> above.
> 
> In the event that one of the commands does not work as expected, it's
> helpful to try alternatives.  E.g. if you can't do name resolutions
> through 192.168.1.1 then try through 8.8.8.8.
> 
> Most plastic routers don't run their own nameserver; instead, they just
> forward your DNS requests to your ISP's nameservers, which may or may
> not be functional on any given day.  So, if 192.168.1.1 fails but
> 8.8.8.8 works, then you know you're going to need to go down the road
> of changing what resolv.conf contains to something usable, a topic upon
> which we've already had a massive discussion within this thread.
> 
> If both 192.168.1.1 and 8.8.8.8 fail, then you may be facing a firewall
> or routing issue.

Last time this came up with this OP, the discussion of whether routers
contain DNS servers ran into the sand unanswered, though the paucity
of lines in their /etc/hosts (localhost plus those allnodes/routers)
seemed to suggest that this one (if it's still the same one) might.

https://lists.debian.org/debian-user/2015/08/msg01349.html

Cheers,
David.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Wed, Oct 04, 2017 at 08:55:51AM -0400, Michael Stone wrote:
> If you are not using resolvconf, a reliable way to stop the isc dhcp client
> from updating resolv.conf is to create
> /etc/dhcp/dhclient-enter-hooks.d/xlocal-nodnsupdate containing
> 
> #!/bin/sh
> make_resolv_conf(){ :; }

You don't need the shebang.  These are dotted in, not executed.

> This overrides the default function. Make sure that file is executable
> (chmod +x /etc/dhcp/dhclient-enter-hooks.d/xlocal-nodnsupdate)

... oh shit, you DO need to set the stupid execute bit, at least
according to dhclient-script(8).

Now I've gotta go run a bunch of chmod commands on all these machines.
To set a bit on a file that is simply read, and should not need an
execute bit.  And I had thought I was done.  *sigh*

Re: Can't find the DNS Servers

[Michael Stone]

On Wed, Oct 04, 2017 at 08:24:16AM -0400, Greg Wooledge wrote:

On Wed, Oct 04, 2017 at 09:11:37AM +0300, Reco wrote:

Locate /etc/dhcp/dhclient.conf. Replace inside it:

request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn…

with:

request subnet-mask, broadcast-address, time-offset, routers,
domain-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn…


See, this is exactly what works for me on one network but NOT on another.
It may work great for the OP of this thread.  It may not.


Yes, that change only causes the dhcp client to stop asking for a name 
server--it does not stop the dhcp server from sending a name server, or 
the client from parsing what the server sends.


If you are not using resolvconf, a reliable way to stop the isc dhcp 
client from updating resolv.conf is to create 
/etc/dhcp/dhclient-enter-hooks.d/xlocal-nodnsupdate 
containing


#!/bin/sh
make_resolv_conf(){ :; }

This overrides the default function. Make sure that file is executable 
(chmod +x /etc/dhcp/dhclient-enter-hooks.d/xlocal-nodnsupdate)


If you are using resolvconf there are other approaches. You might try 
looking at /etc/resolvconf/interface-order (man interface-order) and 
possibly adding something like @enp*([^.]).inet early in the list.


Mike Stone

Re: Can't find the DNS Servers

[Greg Wooledge]

On Tue, Oct 03, 2017 at 04:47:35PM -0700, Gary Roach wrote:
> Symptoms: Any package that needs access to the network sends an error
> message indicating that it doesn't have access to the internet. Ping doesn't
> work for names but does for ip addresses. All ip addresses both local and
> global.

Show, don't tell.

Run some basic diagnostic commands and paste THE COMMANDS and their
output here.

For example,

wooledg:~$ ls -ld /etc/resolv.conf
-rw-r--r-- 1 root root 112 Aug 21 08:29 /etc/resolv.conf

^^ This shows whether resolv.conf is a regular file or a symlink.


wooledg:~$ cat /etc/resolv.conf
domain eeg.ccf.org
search eeg.ccf.org
nameserver 10.76.142.103
nameserver 10.76.142.42
nameserver 172.28.254.24

^^ This shows the CONTENT of resolv.conf, i.e. what the resolver library
inside libc will try to use.


wooledg:~$ ping -c 1 10.76.142.103
PING 10.76.142.103 (10.76.142.103) 56(84) bytes of data.
64 bytes from 10.76.142.103: icmp_seq=1 ttl=63 time=0.431 ms

--- 10.76.142.103 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

^^ This shows that I can ping my nameserver and get a response.


wooledg:~$ host www.debian.org
www.debian.org has address 149.20.4.15
www.debian.org has address 128.31.0.62
www.debian.org has IPv6 address 2001:4f8:1:c::15

^^ This shows a DNS name resolution attempt using resolv.conf but not
libc's resolver.


wooledg:~$ getent hosts www.debian.org
2001:4f8:1:c::15 www.debian.org

^^ This shows a "regular" name lookup attempt using libc's resolver.


wooledg:~$ dig @10.76.142.103 www.debian.org

; <<>> DiG 9.10.3-P4-Debian <<>> @10.76.142.103 www.debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16916
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 6

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.debian.org.IN  A

;; ANSWER SECTION:
www.debian.org. 59  IN  A   128.31.0.62
www.debian.org. 59  IN  A   149.20.4.15

;; AUTHORITY SECTION:
www.debian.org. 28559   IN  NS  geo2.debian.org.
www.debian.org. 28559   IN  NS  geo3.debian.org.
www.debian.org. 28559   IN  NS  geo1.debian.org.

;; ADDITIONAL SECTION:
geo1.debian.org.14775   IN  A   82.195.75.105
geo2.debian.org.14775   IN  A   209.87.16.31
geo2.debian.org.14775   IN  2607:f8f0:614:1::1274:31
geo3.debian.org.14775   IN  A   194.177.211.201
geo3.debian.org.14775   IN  2001:648:2ffc:deb::211:201

;; Query time: 0 msec
;; SERVER: 10.76.142.103#53(10.76.142.103)
;; WHEN: Wed Oct 04 08:29:27 EDT 2017
;; MSG SIZE  rcvd: 236

^^ This shows an explicit DNS name resolution attempt, specifying
the exact nameserver IP to use, and showing full details.


wooledg:~$ dig @8.8.8.8 www.debian.org

; <<>> DiG 9.10.3-P4-Debian <<>> @8.8.8.8 www.debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20704
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.debian.org.IN  A

;; ANSWER SECTION:
www.debian.org. 295 IN  A   149.20.4.15
www.debian.org. 295 IN  A   128.31.0.62

;; Query time: 19 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Oct 04 08:32:59 EDT 2017
;; MSG SIZE  rcvd: 75

^^ This shows an explicit DNS name resolution attempt using Google's
public nameserver.


> In short, there doesn't seem to be any access to a name server. My believe
> that my Actiontec router at 192.168.1.1 also acts as a name server.

In your diagnostic command-and-response session, be sure to include
the results of your attempts to ping your nameserver by IP address,
and of performing a DNS lookup using that nameserver.  See examples
above.

In the event that one of the commands does not work as expected, it's
helpful to try alternatives.  E.g. if you can't do name resolutions
through 192.168.1.1 then try through 8.8.8.8.

Most plastic routers don't run their own nameserver; instead, they just
forward your DNS requests to your ISP's nameservers, which may or may
not be functional on any given day.  So, if 192.168.1.1 fails but
8.8.8.8 works, then you know you're going to need to go down the road
of changing what resolv.conf contains to something usable, a topic upon
which we've already had a massive discussion within this thread.

If both 192.168.1.1 and 8.8.8.8 fail, then you may be facing a firewall
or routing issue.

Re: Can't find the DNS Servers

[Reco]

Hi.

On Wed, Oct 04, 2017 at 08:24:16AM -0400, Greg Wooledge wrote:
> On Wed, Oct 04, 2017 at 09:11:37AM +0300, Reco wrote:
> > Locate /etc/dhcp/dhclient.conf. Replace inside it:
> > 
> > request subnet-mask, broadcast-address, time-offset, routers,
> > domain-name, domain-name-servers, domain-search, host-name
> > dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn…
> > 
> > with:
> > 
> > request subnet-mask, broadcast-address, time-offset, routers,
> > domain-name,
> > dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn…
> 
> See, this is exactly what works for me on one network but NOT on another.
> It may work great for the OP of this thread.  It may not.
> 
> Just a warning.

Have a patience ☺ All goes according to the plan. We'll try [1] next if
this one fails.
I mean - if a Debian Developer proposes it - it should be good, right?

Reco

[1] 
https://lists.debian.org/msgid-search/20170925192045.s7cpppcrpujbo...@qor.donarmstrong.com

Re: Can't find the DNS Servers

[Greg Wooledge]

On Wed, Oct 04, 2017 at 09:11:37AM +0300, Reco wrote:
> Locate /etc/dhcp/dhclient.conf. Replace inside it:
> 
> request subnet-mask, broadcast-address, time-offset, routers,
> domain-name, domain-name-servers, domain-search, host-name
> dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn…
> 
> with:
> 
> request subnet-mask, broadcast-address, time-offset, routers,
> domain-name,
> dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn…

See, this is exactly what works for me on one network but NOT on another.
It may work great for the OP of this thread.  It may not.

Just a warning.

Re: Can't find the DNS Servers

[Reco]

Hi.

On Tue, Oct 03, 2017 at 01:30:11PM -0700, Gary Roach wrote:
> OK Rico> I followed your instructions and still have the same problem.
> Attached are the new files. Already installed were isc-dhcp-client and
> resolvconf. You are right about the br1 entry not being needed. the virtual
> machine works fine without it.

So, what we have now is a definite improvement over the last time, but
some twists are needed.

While "dns-nameserver" stanzas are working now, your DHCP server also
advertises its own:

> # 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.1.1
> nameserver 8.8.8.8
> nameserver 8.8.4.4

A correct way to fix this is to "persuade" your DHCP server not to
provide DNS information.
Even more correct way is to force your DNS-at-DHCP to use 8.8.8.8 as
forwarder DNS.
Since it's unnaturally complex to do so in a consumer-grade routers, a
hack is in order.

Locate /etc/dhcp/dhclient.conf. Replace inside it:

request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn…

with:

request subnet-mask, broadcast-address, time-offset, routers,
domain-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn…

Bounce your primary network interface.

I've attached diff to this e-mail for this modification.

Reco
--- a/etc/dhcp/dhclient.conf	2016-11-26 06:44:00.0 +
+++ b/etc/dhcp/dhclient.conf	2017-10-04 06:09:07.176684386 +
@@ -14,7 +14,7 @@

 send host-name = gethostname();
 request subnet-mask, broadcast-address, time-offset, routers,
-   domain-name, domain-name-servers, domain-search, host-name,
+   domain-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes, ntp-servers;

Re: Can't find the DNS Servers

[Gary Roach]

On 10/03/2017 03:53 PM, David Wright wrote:

On Tue 03 Oct 2017 at 13:30:11 (-0700), Gary Roach wrote:

OK Rico> I followed your instructions and still have the same
problem. Attached are the new files. Already installed were
isc-dhcp-client and resolvconf. You are right about the br1 entry
not being needed. the virtual machine works fine without it.


Perhaps you need to rereport your symptoms. Indeed, report them
at all: you said ping worked; pinging what? Can you ping the
loopback? the router? other local hosts, by number or by name?
8.8.8.8? "The same problem" doesn't cut it. At least you've now
got the external nameservers in your resolv.conf. And does your
router do DNS or not?

Cheers,
David.


Symptoms: Any package that needs access to the network sends an error 
message indicating that it doesn't have access to the internet. Ping 
doesn't work for names but does for ip addresses. All ip addresses both 
local and global.


In short, there doesn't seem to be any access to a name server. My 
believe that my Actiontec router at 192.168.1.1 also acts as a name server.


Thanks for the help

Gary R

Re: Can't find the DNS Servers

[David Wright]

On Tue 03 Oct 2017 at 13:30:11 (-0700), Gary Roach wrote:
> OK Rico> I followed your instructions and still have the same
> problem. Attached are the new files. Already installed were
> isc-dhcp-client and resolvconf. You are right about the br1 entry
> not being needed. the virtual machine works fine without it.

Perhaps you need to rereport your symptoms. Indeed, report them
at all: you said ping worked; pinging what? Can you ping the
loopback? the router? other local hosts, by number or by name?
8.8.8.8? "The same problem" doesn't cut it. At least you've now
got the external nameservers in your resolv.conf. And does your
router do DNS or not?

Cheers,
David.

Re: Can't find the DNS Servers

[Gary Roach]

OK Rico> I followed your instructions and still have the same problem. 
Attached are the new files. Already installed were isc-dhcp-client and 
resolvconf. You are right about the br1 entry not being needed. the 
virtual machine works fine without it.


Gary R
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).


## The loopback network interface
auto lo
iface lo inet loopback

##The primary network interface
auto enp4s0
iface enp4s0 inet dhcp
  dns-nameserver 8.8.8.8
  dns-nameserver 8.8.4.4


##The bridge network interface to qemu virtual machine
#auto br1
#iface br1 inet dhcp
#   bridge_ports br1
#   bridge_stp off
#   bridge_fd 0.0


default 0.0.0.0
loopback127.0.0.0
link-local  169.254.0.0

# 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.1.1
nameserver 8.8.8.8
nameserver 8.8.4.4
search home
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp4s0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 4c:cc:6a:87:fb:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.6/24 brd 192.168.1.255 scope global dynamic enp4s0
   valid_lft 84574sec preferred_lft 84574sec
inet6 fe80::5447:c98c:3f23:efe8/64 scope link 
   valid_lft forever preferred_lft forever
3: virbr0:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether 52:54:00:d1:d9:de brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
   valid_lft forever preferred_lft forever
4: virbr0-nic:  mtu 1500 qdisc pfifo_fast master virbr0 
state DOWN group default qlen 1000
link/ether 52:54:00:d1:d9:de brd ff:ff:ff:ff:ff:ff
default via 192.168.1.1 dev enp4s0 proto static metric 100 
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.6 metric 100 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 

Re: Can't find the DNS Servers

[David Wright]

On Mon 02 Oct 2017 at 21:32:40 (+0300), Reco wrote:
>   Hi.
> 
> On Mon, Oct 02, 2017 at 11:15:16AM -0500, David Wright wrote:
> > On Mon 02 Oct 2017 at 10:00:28 (+0300), Reco wrote:
> > 
> > > To bring order to this chaos, you'll need this e/n/i:
> > > 
> > > auto enp4s0
> > > iface enp4s0 inet dhcp
> > >   dns-nameserver 8.8.4.4
> > >   dns-nameserver 8.8.8.8
> > > 
> > > Please note the indentation,
> > 
> > … which looks tidy, but the indentation carries no meaning
> > (lest people spend time fiddling with it thinking that it does).
> 
> While the indentation is ignored by ifupdown indeed, it carries
> invaluable meaning to human beings.
> In this particular case, the meaning is:
> 
> Both "dns-nameserver" stanzas are applied to enp4s0 interface only, not
> that other one, and even not the one you want it to apply to.

… which is precisely the delusion.

> Also, one should promote neatness in configuration files.

By all means. But this is just as tidy without adding
meaningless "meanings":



## Primary network interface ##

auto  enp4s0
iface enp4s0 inet dhcp
dns-nameserver 8.8.4.4
dns-nameserver 8.8.8.8

## Bridging stuff #

[… … …]



Cheers,
David.

Re: Can't find the DNS Servers

[Reco]

Hi.

On Mon, Oct 02, 2017 at 11:15:16AM -0500, David Wright wrote:
> On Mon 02 Oct 2017 at 10:00:28 (+0300), Reco wrote:
> 
> > To bring order to this chaos, you'll need this e/n/i:
> > 
> > auto enp4s0
> > iface enp4s0 inet dhcp
> > dns-nameserver 8.8.4.4
> > dns-nameserver 8.8.8.8
> > 
> > Please note the indentation,
> 
> … which looks tidy, but the indentation carries no meaning
> (lest people spend time fiddling with it thinking that it does).

While the indentation is ignored by ifupdown indeed, it carries
invaluable meaning to human beings.
In this particular case, the meaning is:

Both "dns-nameserver" stanzas are applied to enp4s0 interface only, not
that other one, and even not the one you want it to apply to.


Also, one should promote neatness in configuration files. Otherwise
first you put tiny amounts of badly-formatted configuration stanzas,
next you're going Slackware by configure/make/make install and *finally*
you're trying to parse HTML with regular expressions bringing doom and
demise to unsuspecting humankind.

Reco

Re: Can't find the DNS Servers

[David Wright]

On Mon 02 Oct 2017 at 06:26:08 (-0400), Gene Heskett wrote:
> On Monday 02 October 2017 03:00:28 Reco wrote:
> 
> > Hi.
> >
> > On Sun, Oct 01, 2017 at 07:26:30PM -0700, Gary Roach wrote:
> > > This is the second time I've tried to send this. The first one just
> > > disappeared to the bit bucket I assume. So lets try again.
> >
> > It did not. Everyone on the list got it, I believe.
> >
> You are using gmail. To gmail, the echo from the list is a duplicate, and 
> deleted. Just one of the reasons I left gmail.

As Reco wrote, the OP posted twice. My response to the first post
was already six minutes old by the time the OP reposted.
(Reco's response was much more thorough.)

Cheers,
David.

Re: Can't find the DNS Servers

[David Wright]

On Mon 02 Oct 2017 at 10:00:28 (+0300), Reco wrote:

> To bring order to this chaos, you'll need this e/n/i:
> 
> auto enp4s0
> iface enp4s0 inet dhcp
>   dns-nameserver 8.8.4.4
>   dns-nameserver 8.8.8.8
> 
> Please note the indentation,

… which looks tidy, but the indentation carries no meaning
(lest people spend time fiddling with it thinking that it does).

Cheers,
David.

Re: Can't find the DNS Servers

[Gene Heskett]

On Monday 02 October 2017 03:00:28 Reco wrote:

>   Hi.
>
> On Sun, Oct 01, 2017 at 07:26:30PM -0700, Gary Roach wrote:
> > This is the second time I've tried to send this. The first one just
> > disappeared to the bit bucket I assume. So lets try again.
>
> It did not. Everyone on the list got it, I believe.
>
You are using gmail. To gmail, the echo from the list is a duplicate, and 
deleted. Just one of the reasons I left gmail.

[...]

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[Reco]

Hi.

On Sun, Oct 01, 2017 at 07:26:30PM -0700, Gary Roach wrote:
> This is the second time I've tried to send this. The first one just
> disappeared to the bit bucket I assume. So lets try again.

It did not. Everyone on the list got it, I believe.

> Sorry about the delay in replying to your request. Attached is the
> information you requested. I could not find nameservers 8.8.8.8 and 8.8.4.4
> listed anywhere. This is probably the root of my problem.

No, your problem is different.

> I tried every
> thing I could think of but couldn't get them to stick in resolv.conf.

So, let's get this party started.

First, you have "eth0" defined in your /etc/network/interfaces.
A simple DHCP configuration that *can*, but *does not* honor your
"dns-nameserver" stanzas.
The reason being - you put them *after* br1 interface.

Second, you have "br1" bridge that:

1) Tries to bridge itself. Nothing good will ever come out of this.

2) Does not try to bridge eth0. I don't know, it may be intended.

3) Does not have *auto* keyword defined, so this bridge does not come
into play.

Third, and that's no wonder, you have so-called Predictable NIC Names
configured, so your *actual* interface is called enp4s0, not eth0.
Therefore e/n/i does not apply to it, something else was used to
configure it.

Fourth, you have your virbr0 interface presumably configured by libvirt.
Which means that it's configured at
/etc/libvirt/qemu/networks/default.xml or maybe some other file at
/etc/libvirt/qemu/networks.

Routing table does not contain anything unusual, as does
/etc/resolv.conf.


To bring order to this chaos, you'll need this e/n/i:

auto enp4s0
iface enp4s0 inet dhcp
dns-nameserver 8.8.4.4
dns-nameserver 8.8.8.8

Please note the indentation, and that I deliberately omitted "br1". You
don't need it anyway, you have libvirt to take care of bridging.

What you also need is:

1) resolvconf package. dns-nameserver stanzas are ignored unless you
install it.

2) Any kind of dhcp client. A stock isc-dhcp-client should do it.

3) Deinstalling (disabling) whatever you're using now to configure
enp4s0 now.

4) libvirt-doc package. After you restore your primary network
connectivity, please point your browser to
/usr/share/doc/libvirt-doc/formatnetwork.html .

Reco

Re: Can't find the DNS Servers

[Weaver]

On 2017-10-02 12:26, Gary Roach wrote:
> On 09/27/2017 09:31 AM, Reco wrote:
>> On Wed, Sep 27, 2017 at 10:16:20PM +1300, Richard Hector wrote:
>>> On 26/09/17 19:50, Reco wrote:
 Please post these things from the problematic PC:

 ip a l

 ip ro l
>>>
>>> Can I make a request? When giving example commands, can you give them in
>>> full, rather than abbreviated?
>>
>> Sure,
>>
>> ip address list
>>
>> ip route list
>>
>>
>>> I believe 'a' and 'ro' are 'address' and 'route' respectively,
>>
>> Yep.
>>
>>> but 'l'
>>> is a bit harder to find - not in the result of "ip address help",
>>> anyway. 'list' perhaps? Which I think is the default anyway?
>>
>> It's 'list' indeed. 'ip a l' is a personal habit.
>>
>>
>>> I believe anyone who knows the short versions will know the long ones,
>>> and those who don't won't have to go digging up the manpages to
>>> understand what's going on :-)
>>
>> I've requested these commands as I suspect that current IPv4 routing of
>> that host prevents it to talk to configured DNSes.
>>
>> Of course, it might as well be:
>>
>> 1) Misconfigured 'nat' netfilter table (libvirt can do some strange
>> things in this regard for instance).
>>
>> 2) Misconfigured 'filter' netfilter table (iptables are teh hard
>> sometimes).
>>
>> 3) Misconfigured 'mangle' netfilter table (forced UDP checksumming for
>> no good reason).
>>
>> 4) Misconfigured IPv6.
>>
>> 5) All those martian green men that wish evil to us all.
>>
>> But in cases like this I like to search for simple explanation first,
>> and proceed to complex ones after.
>>
>>
>> PS I agree that iproute's manpages have a great improvement potential.
>> Speaking lightly ☺.
>>
>> Reco
>>
>>
> This is the second time I've tried to send this. The first one just
> disappeared to the bit bucket I assume. So lets try again.
> Sorry about the delay in replying to your request. Attached is the
> information you requested. I could not find nameservers 8.8.8.8 and
> 8.8.4.4 listed anywhere. This is probably the root of my problem. I
> tried every thing I could think of but couldn't get them to stick in
> resolv.conf.

I received it the first time, for reference.

-- 
"It is the duty of the patriot to protect his country from its 
government."
 -- Thomas Paine

Registered Linux User: 554515

Re: Can't find the DNS Servers

[Gary Roach]

On 09/27/2017 09:31 AM, Reco wrote:

On Wed, Sep 27, 2017 at 10:16:20PM +1300, Richard Hector wrote:

On 26/09/17 19:50, Reco wrote:

Please post these things from the problematic PC:

ip a l

ip ro l


Can I make a request? When giving example commands, can you give them in
full, rather than abbreviated?


Sure,

ip address list

ip route list



I believe 'a' and 'ro' are 'address' and 'route' respectively,


Yep.


but 'l'
is a bit harder to find - not in the result of "ip address help",
anyway. 'list' perhaps? Which I think is the default anyway?


It's 'list' indeed. 'ip a l' is a personal habit.



I believe anyone who knows the short versions will know the long ones,
and those who don't won't have to go digging up the manpages to
understand what's going on :-)


I've requested these commands as I suspect that current IPv4 routing of
that host prevents it to talk to configured DNSes.

Of course, it might as well be:

1) Misconfigured 'nat' netfilter table (libvirt can do some strange
things in this regard for instance).

2) Misconfigured 'filter' netfilter table (iptables are teh hard
sometimes).

3) Misconfigured 'mangle' netfilter table (forced UDP checksumming for
no good reason).

4) Misconfigured IPv6.

5) All those martian green men that wish evil to us all.

But in cases like this I like to search for simple explanation first,
and proceed to complex ones after.


PS I agree that iproute's manpages have a great improvement potential.
Speaking lightly ☺.

Reco


This is the second time I've tried to send this. The first one just 
disappeared to the bit bucket I assume. So lets try again.
Sorry about the delay in replying to your request. Attached is the 
information you requested. I could not find nameservers 8.8.8.8 and 
8.8.4.4 listed anywhere. This is probably the root of my problem. I 
tried every thing I could think of but couldn't get them to stick in 
resolv.conf.


Gary R.
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).


## The loopback network interface
auto lo
iface lo inet loopback

##The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp


##The bridge network interface to qemu virtual machine
#auto br1
iface br1 inet dhcp
   bridge_ports br1
   bridge_stp off
   bridge_fd 0.0

dns-nameserver 8.8.8.8
dns-nameserver 8.8.4.4

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).


## The loopback network interface
auto lo
iface lo inet loopback

##The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp


##The bridge network interface to qemu virtual machine
#auto br1
iface br1 inet dhcp
   bridge_ports br1
   bridge_stp off
   bridge_fd 0.0

dns-nameserver 8.8.8.8
dns-nameserver 8.8.4.4

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp4s0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 4c:cc:6a:87:fb:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic enp4s0
   valid_lft 63501sec preferred_lft 63501sec
inet6 fe80::4ecc:6aff:fe87:fb5d/64 scope link 
   valid_lft forever preferred_lft forever
3: virbr0:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether 52:54:00:d1:d9:de brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
   valid_lft forever preferred_lft forever
4: virbr0-nic:  mtu 1500 qdisc pfifo_fast master virbr0 
state DOWN group default qlen 1000
link/ether 52:54:00:d1:d9:de brd ff:ff:ff:ff:ff:ff
default via 192.168.1.1 dev enp4s0 proto static metric 100 
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.10 metric 100 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
# 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.1.1
search home

Re: Can't find the DNS Servers

[David Wright]

On Sun 01 Oct 2017 at 13:36:28 (-0700), Gary Roach wrote:
> OK, I've been remiss in getting you the information requested. I
> think what you need is in the attachments. Nowhere have I found
> reference to 8.8.8.8 and 8.8.4.4 name servers. I have tried serveral
> different ways to get them into the resolv.conf files and have
> failed.
> 
> Gary R.

> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> 
> ## The loopback network interface
> auto lo
> iface lo inet loopback
> 
> ##The primary network interface
> allow-hotplug eth0
> iface eth0 inet dhcp
> 
> 
> ##The bridge network interface to qemu virtual machine
> #auto br1
> iface br1 inet dhcp
>bridge_ports br1
>bridge_stp off
>bridge_fd 0.0
> 
> dns-nameserver 8.8.8.8
> dns-nameserver 8.8.4.4
> 

> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).
> 
> 
> ## The loopback network interface
> auto lo
> iface lo inet loopback
> 
> ##The primary network interface
> allow-hotplug eth0
> iface eth0 inet dhcp
> 
> 
> ##The bridge network interface to qemu virtual machine
> #auto br1
> iface br1 inet dhcp
>bridge_ports br1
>bridge_stp off
>bridge_fd 0.0
> 
> dns-nameserver 8.8.8.8
> dns-nameserver 8.8.4.4
> 

Disclaimer: I know nothing about bridging, sorry.

Why doesn't this file have:

## The loopback network interface
auto lo
iface lo inet loopback

##The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp
dns-nameserver 8.8.8.8← in the eth0 interface stanza
dns-nameserver 8.8.4.4← ditto

##The bridge network interface to qemu virtual machine
#auto br1
iface br1 inet dhcp
bridge_ports br1
bridge_stp off
bridge_fd 0.0

## … and then nameserver lines if bridging requires them.

Cheers,
David.

Re: Can't find the DNS Servers

[Gary Roach]

On 09/27/2017 09:31 AM, Reco wrote:

On Wed, Sep 27, 2017 at 10:16:20PM +1300, Richard Hector wrote:

On 26/09/17 19:50, Reco wrote:

Please post these things from the problematic PC:

ip a l

ip ro l


Can I make a request? When giving example commands, can you give them in
full, rather than abbreviated?


Sure,

ip address list

ip route list



I believe 'a' and 'ro' are 'address' and 'route' respectively,


Yep.


but 'l'
is a bit harder to find - not in the result of "ip address help",
anyway. 'list' perhaps? Which I think is the default anyway?


It's 'list' indeed. 'ip a l' is a personal habit.



I believe anyone who knows the short versions will know the long ones,
and those who don't won't have to go digging up the manpages to
understand what's going on :-)


I've requested these commands as I suspect that current IPv4 routing of
that host prevents it to talk to configured DNSes.

Of course, it might as well be:

1) Misconfigured 'nat' netfilter table (libvirt can do some strange
things in this regard for instance).

2) Misconfigured 'filter' netfilter table (iptables are teh hard
sometimes).

3) Misconfigured 'mangle' netfilter table (forced UDP checksumming for
no good reason).

4) Misconfigured IPv6.

5) All those martian green men that wish evil to us all.

But in cases like this I like to search for simple explanation first,
and proceed to complex ones after.


PS I agree that iproute's manpages have a great improvement potential.
Speaking lightly ☺.

Reco


OK, I've been remiss in getting you the information requested. I think 
what you need is in the attachments. Nowhere have I found reference to 
8.8.8.8 and 8.8.4.4 name servers. I have tried serveral different ways 
to get them into the resolv.conf files and have failed.


Gary R.
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).


## The loopback network interface
auto lo
iface lo inet loopback

##The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp


##The bridge network interface to qemu virtual machine
#auto br1
iface br1 inet dhcp
   bridge_ports br1
   bridge_stp off
   bridge_fd 0.0

dns-nameserver 8.8.8.8
dns-nameserver 8.8.4.4

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).


## The loopback network interface
auto lo
iface lo inet loopback

##The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp


##The bridge network interface to qemu virtual machine
#auto br1
iface br1 inet dhcp
   bridge_ports br1
   bridge_stp off
   bridge_fd 0.0

dns-nameserver 8.8.8.8
dns-nameserver 8.8.4.4

1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: enp4s0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
link/ether 4c:cc:6a:87:fb:5d brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global dynamic enp4s0
   valid_lft 63501sec preferred_lft 63501sec
inet6 fe80::4ecc:6aff:fe87:fb5d/64 scope link 
   valid_lft forever preferred_lft forever
3: virbr0:  mtu 1500 qdisc noqueue state 
DOWN group default qlen 1000
link/ether 52:54:00:d1:d9:de brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
   valid_lft forever preferred_lft forever
4: virbr0-nic:  mtu 1500 qdisc pfifo_fast master virbr0 
state DOWN group default qlen 1000
link/ether 52:54:00:d1:d9:de brd ff:ff:ff:ff:ff:ff
default via 192.168.1.1 dev enp4s0 proto static metric 100 
192.168.1.0/24 dev enp4s0 proto kernel scope link src 192.168.1.10 metric 100 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
# 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.1.1
search home

Re: Can't find the DNS Servers

[Curt]

On 2017-09-30, Gary Roach  wrote:
>>
> Well the philosophy and stories are nice but my access to the internet 
> is still among the missing. I have a Debian Stretch system installed and 
> am using NetworkManager. This worked until I installed qemu virtual 
> machine over the host OS. Since then the host system does not seem able 
> to find a DNS server. The really strange thing is that I installed 
> Kubuntu as the guest OS and that works fine. I suspect that qemu has 
> glommed onto the eth0 device and won't let the host in. I have gone
> over and over the NetworkManager documentation and have found no way
> to fix this. The situation is getting critical. I need to load some
> software into the host system and can't, I also can't upgrade the
> system and can't.

You're in good hands with Reco and Hambourg, however I read that libvirt
creates iptable rules, uses dnsmasq, but actually I don't understand any
of this--had I understood something I probably would have said to turn
that stuff off to troubleshoot, if you haven't already.


> I really need some help here.
>
> Gary R
>
>


-- 
"A simpering Bambi narcissist and a thieving, fanatical Albanian dwarf."
Christopher Hitchens, commenting shortly after the nearly concurrent deaths 
of Lady Diana and Mother Theresa.

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 30/09/2017 à 04:18, Gary Roach a écrit :


Well the philosophy and stories are nice but my access to the internet 
is still among the missing.


We are waiting for the information asked by Reco several days ago :

ip address list

ip route list

cat /etc/resolv.conf

tcpdump -nvi any udp port 53 or tcp port 53
run while doing
getent hosts www.debian.org

Re: Can't find the DNS Servers

[Gary Roach]

On 09/25/2017 07:20 AM, Pascal Hambourg wrote:

Le 25/09/2017 à 15:54, Greg Wooledge a écrit :

On Mon, Sep 25, 2017 at 03:45:06PM +0200, Pascal Hambourg wrote:

Prepare to be disappointed if you modify directly resolv.conf,
because the
software which wrote it first could rewrite it after you, as DHCP
clients do
each time they renew the lease.


In a battle between me and stupid new software programs, I always win
in the end.


I hope so. The user shall prevail.


I will do whatever it takes to make the software behave correctly,
even if what it takes is REMOVING the software.


For sure. But there is the forcible way and the graceful way.

Here is a little experience of mine.
I had a host configured with DHCP. As expected, dhclient wrote the IPv4
DNS addresses received from the DHCP server into resolv.conf. My network
also had an IPv6 router sending advertisements containing IPv6 DNS
addresses and I wanted that addresses to be included in resolv.conf, so
I installed rdnssd. Unfortunatly, both dhclient and rdnssd rewrote
resolv.conf, erasing the addresses added by the other. Either DNS
addresses worked, but it was not what I wanted. Then I installed
resolvconf and resolv.conf now contained both IPv4 addresses from
dhclient and IPv6 addresses from rdnssd.


Well the philosophy and stories are nice but my access to the internet 
is still among the missing. I have a Debian Stretch system installed and 
am using NetworkManager. This worked until I installed qemu virtual 
machine over the host OS. Since then the host system does not seem able 
to find a DNS server. The really strange thing is that I installed 
Kubuntu as the guest OS and that works fine. I suspect that qemu has 
glommed onto the eth0 device and won't let the host in. I have gone over 
and over the NetworkManager documentation and have found no way to fix 
this. The situation is getting critical. I need to load some software 
into the host system and can't, I also can't upgrade the system and can't.


I really need some help here.

Gary R

Re: Can't find the DNS Servers

[Reco]

On Wed, Sep 27, 2017 at 10:16:20PM +1300, Richard Hector wrote:
> On 26/09/17 19:50, Reco wrote:
> > Please post these things from the problematic PC:
> > 
> > ip a l
> > 
> > ip ro l
> 
> Can I make a request? When giving example commands, can you give them in
> full, rather than abbreviated?

Sure,

ip address list

ip route list


> I believe 'a' and 'ro' are 'address' and 'route' respectively,

Yep.

> but 'l'
> is a bit harder to find - not in the result of "ip address help",
> anyway. 'list' perhaps? Which I think is the default anyway?

It's 'list' indeed. 'ip a l' is a personal habit.


> I believe anyone who knows the short versions will know the long ones,
> and those who don't won't have to go digging up the manpages to
> understand what's going on :-)

I've requested these commands as I suspect that current IPv4 routing of
that host prevents it to talk to configured DNSes.

Of course, it might as well be:

1) Misconfigured 'nat' netfilter table (libvirt can do some strange
things in this regard for instance).

2) Misconfigured 'filter' netfilter table (iptables are teh hard
sometimes).

3) Misconfigured 'mangle' netfilter table (forced UDP checksumming for
no good reason).

4) Misconfigured IPv6.

5) All those martian green men that wish evil to us all.

But in cases like this I like to search for simple explanation first,
and proceed to complex ones after.


PS I agree that iproute's manpages have a great improvement potential.
Speaking lightly ☺.

Reco

Re: Finding the appropriate manpage [Re: Can't find the DNS Servers]

[Curt]

On 2017-09-27, Lck Ras  wrote:
> On 09/27/2017 06:16 AM, Don Armstrong wrote:
>> In almost every case, if you don't know the right man page, apropos (or
>> man -k) will help you find it. If that's not good enough, man -K
>> dhclient will eventually find all of them.
>> 
>> dhclient (8) - Dynamic Host Configuration Protocol Client
>> dhclient-script (8)  - DHCP client network configuration script
>> dhclient.conf (5)- DHCP client configuration file
>> dhclient.leases (5)  - DHCP client lease database
>
> Plus the dhclient(8) manpage lists other related manuals in its SEE ALSO
> section:
>
> SEE ALSO
>dhcpd(8),  dhcrelay(8),  dhclient-script(8),  dhclient.conf(5),
>dhclient.leases(5), dhcp-eval(5).
>

Plus there is a new thing in town called the Internet, an extensive
respository of searchable knowledge (as well as invidious horseshit).

I put 'dhclient resolv.conf' into the Evil Search Engine (TM) and the very
first hit spoke of the very dhclient-script hookerino suggested by D.
Armstrong.

For kicks, I just put the following search terms in the search engine
mentioned above, in plain English:

 how do you prevent dhclient from modifying resolv.conf

First hit, third post in the thread, D. Armstrong's hookerino:

https://www.centos.org/forums/viewtopic.php?t=24741

Put me down as unconvinced (by anything--I know, I know, this has
nothing to do with man pages, but if 'they' can change the subject in
mid-stream, why can't I--though I didn't, I mean up there)?



-- 
"A simpering Bambi narcissist and a thieving, fanatical Albanian dwarf."
Christopher Hitchens, commenting shortly after the nearly concurrent deaths 
of Lady Diana and Mother Theresa.

Re: Finding the appropriate manpage [Re: Can't find the DNS Servers]

[Lck Ras]

On 09/27/2017 06:16 AM, Don Armstrong wrote:
> In almost every case, if you don't know the right man page, apropos (or
> man -k) will help you find it. If that's not good enough, man -K
> dhclient will eventually find all of them.
> 
> dhclient (8) - Dynamic Host Configuration Protocol Client
> dhclient-script (8)  - DHCP client network configuration script
> dhclient.conf (5)- DHCP client configuration file
> dhclient.leases (5)  - DHCP client lease database

Plus the dhclient(8) manpage lists other related manuals in its SEE ALSO
section:

SEE ALSO
   dhcpd(8),  dhcrelay(8),  dhclient-script(8),  dhclient.conf(5),
   dhclient.leases(5), dhcp-eval(5).

Re: Can't find the DNS Servers

[Richard Hector]

On 26/09/17 19:50, Reco wrote:
> Please post these things from the problematic PC:
> 
> ip a l
> 
> ip ro l

Can I make a request? When giving example commands, can you give them in
full, rather than abbreviated?

I believe 'a' and 'ro' are 'address' and 'route' respectively, but 'l'
is a bit harder to find - not in the result of "ip address help",
anyway. 'list' perhaps? Which I think is the default anyway?

I believe anyone who knows the short versions will know the long ones,
and those who don't won't have to go digging up the manpages to
understand what's going on :-)

Cheers,

Richard



signature.asc
Description: OpenPGP digital signature

Re: Can't find the DNS Servers

[Gene Heskett]

On Tuesday 26 September 2017 15:47:57 Greg Wooledge wrote:

> On Tue, Sep 26, 2017 at 03:19:51PM -0400, Gene Heskett wrote:
> > > domain coyote.den
> >
> > This I think is a leftover from when it was the place to put your
> > domainname, but now we've had the domainname utility to set that for
> > what, a decade?, and I could probably remove that line.  Belt and
> > suspenders I guess.  :)
>
> The domainname(1) command is for NIS, not DNS.
>
> The "domain" directive in resolv.conf is deprecated (maybe?) in favor
> of the "search" list, but the latter is a list of domain names, not
> places to consult.  (If "domain" is given and "search" is not, then
> "search" uses the name that is in "domain" as its only entry.)
>
> The list of places to consult for name resolution is in
> /etc/nsswitch.conf in recent releases, and was in /etc/host.conf a
> very long time ago.

Sounds like I must have missed that memo. Lets see what it says: For 
starters, 13 keywords, yikes.  Even so, it could be called a bit too 
concise and will take some study to adequately decipher them all. But I 
have a new parted problem I'll post about next.

Thanks Greg.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[Gene Heskett]

On Tuesday 26 September 2017 15:43:35 Greg Wooledge wrote:

> On Tue, Sep 26, 2017 at 03:33:48PM -0400, Gene Heskett wrote:
> > > > nameserver 192.168.XX.1
> > > > search host dns
> > > > domain coyote.den
> >
> > I started with Red Hat 5.0, in the late '90's. And it looks like
> > stretch may have deprecated the executable, locate can only find the
> >  .conf files, one in /etc, and one in 
> > /usr/share/libc-bin/nsswitch.conf. Maybe its something libc-bin
> > uses? They are identical FWTW.
>
> From Red Hat 5.2 (Apollo) resolver(5):
>
>
> NAME
>  resolver - resolver configuration file
>
> SYNOPSIS
>  /etc/resolv.conf
>
> ...
>  search   Search list for host-name lookup.  The search list is
> normally determined from the local domain name; by default, it
> contains only the local domain name.  This may be changed by listing
> the desired domain search path following the search keyword with
> spaces or tabs separating the names.  Most resolver queries will be
> attempted using each component of the search path in turn un- til a
> match is found.  Note that this process may be slow and will generate
> a lot of network traffic if the servers for the listed domains are not
> local, and that queries will time out if no server is available for
> one of the domains.
>
>   The search list is currently limited to six domains with
> a total of 256 characters.
> ...
> 4th Berkeley Distribution  November 11, 1993  
>   1
>
>
> I still think you're carrying along some mistake that you made decades
> ago, which has simply never caused any problems, but is also not doing
> anything beneficial.  But if you can tell us *which* man page you saw
> this in, that would be of interest.
>
> P.S. there's nothing new in stretch here.  Even the wheezy man page
> for resolv.conf(5) looks basically the same as stretch's.  Compare:
>
> https://manpages.debian.org/wheezy/manpages/resolv.conf.5.en.html
> https://manpages.debian.org/stretch/manpages/resolv.conf.5.en.html

For stretch, I'm looking at the manpage from an arm64 based card.  And 
I've checked the rest of the mostly wheezy machines. The first machine, 
running my G0704 had:
order hosts nameserver

and its worked well that way for 2 years. But I changed it out for 
search etc etc anyway.

next is the ark/intel shoebox running a small Chinese 7x12 lathe I call 
lathe, affectionately known as TLM, for The Little Monster, it has a 1 
hp spindle motor and is forever breaking drive parts.

It has only one line, the nameserver address in the router, which must 
know about the local net as it can ping the rest of the machines just 
fine.  So that one is wrong, and its been wrong since sometime in July 
2015. I really ought to fix it.  But it also Just Works(TM).

Next is a small 4 axis milling machine called shop. It has:
search hosts,dns
nameserver 192.168.71.1

note comma, wrong according to the man page as its says spaces or tabs 
for separators. But its been that way since the last install in  July 
2015.

No problems that have made me question the net config in the last 27 
months.

Next, back in the garage, where a raspberry pi 3b is currently running a 
much bigger Sheldon lathe. Its running jessie. And says:
search hosts,dns
nameserver 192.168.71.1

Note comma, which the man page says is wrong. But it, like the other 4, 
works.

And finally from the stretch install on a rock64 that I hope can replace 
the pi:
rock64@rock64Sheldon:/usr/share/man$ cat /etc/resolv.conf
## screw dhcpd, can't find its ass with both hands!
domain coyote.den
nameserver 192.168.71.1
search  hosts   nameserver

 But the network stuff there is doofy, I have to specify the gateway 
twice to actually get it into the route -n output.
cat /etc/network/interfaces.d/eth0
auto eth0
iface eth0 inet static
address 192.168.71.2/24
gateway 192.168.71.1
up route add default gw 192.168.71.1

If I remove either of the last 2 lines, no gateway. And I haven't a clue.

So theres at least 3 variations on this theme, all of which work.
And I found I can't run a calculator and parted at the same time. So when 
I told mkswap to make swap on the 2nd partition on a terabyte drive, 
which I thought I'd set to 2GB, twice its memory, when I got around to 
doing a mkswap, and adding it to /etc/fstab, then doing a swapon -a, 
imagine my surprise to see htop telling me I had 7532MB of swap. But it 
has drive to throw away anyway.  Shrug. :)

And the stretch man page is the same as wheezy's ANAICT. The final 
paragraph:

 The domain and search keywords are mutually exclusive.  If more than one 
instance of these keywords is present, the last instance wins.

   The search keyword of a system's resolv.conf file can be 
overridden on a per-process basis by setting the environment variable 
LOCALDOMAIN to a space-separated list
   of search domains.

   The  options  keyword of a system's resolv.conf file can be 
amended on a per-process basis by setting the 

Re: Can't find the DNS Servers

[David Wright]

On Tue 26 Sep 2017 at 14:59:41 (-0400), Greg Wooledge wrote:
> On Tue, Sep 26, 2017 at 01:42:39PM -0500, David Wright wrote:
> > On this topic, I still can't understand the contents of your
> > immutable /etc/resolv.conf file, even without the comma:
> > 
> > nameserver 192.168.XX.1
> > search host dns
> > domain coyote.den
> > 
> > Can you detail these domains called host and dns?
> 
> I keep thinking that it's some relic from libc4 or libc5, before the
> adoption of nsswitch.conf, but I am at a loss how to find documentation
> that old to prove or disprove my guess.
> 
> The nearest I could find is 
> which describes an /etc/host.conf file that contains "order bind hosts".
> I can't tell whether Gene's setup is an erroneous take on this obsolete
> configuration file (somehow merging it into resolv.conf), or something
> else entirely.  Perhaps something even older, or something from a
> non-Linux system.

Oh yes, I think you're right. It even explains the comma that Gene
had in the file until this month. I see that my own ancient host.conf
still had   order hosts,bind   in it in 2000. The example with
 in your reference seems to be unusual.

Judging by my ancient email logs (Subject: lines only), there was a
flurry around July 1998 which was about when libc6 started (hamm).

Cheers,
David.

Finding the appropriate manpage [Re: Can't find the DNS Servers]

[Don Armstrong]

On Tue, 26 Sep 2017, Greg Wooledge wrote:
> For years, I have been searching back and forth and up and down in
> dhclient(8) and dhclient.conf(5) and finding NOTHING.

> Turns out the REASON I couldn't find anything was because some bright
> spark decided to split the documentation into multiple man pages.

> So, apparently the only way to find anything is to open umpteen
> terminal windows, one man page in each terminal window.

In almost every case, if you don't know the right man page, apropos (or
man -k) will help you find it. If that's not good enough, man -K
dhclient will eventually find all of them.

dhclient (8) - Dynamic Host Configuration Protocol Client
dhclient-script (8)  - DHCP client network configuration script
dhclient.conf (5)- DHCP client configuration file
dhclient.leases (5)  - DHCP client lease database

alternatively, you could run dpkg -L isc-dhcp-client|grep man; to see
all of the manpages that the dhcp client provides:

/usr/share/man/man5/dhclient.conf.5.gz
/usr/share/man/man5/dhclient.leases.5.gz
/usr/share/man/man8/dhclient-script.8.gz
/usr/share/man/man8/dhclient.8.gz


-- 
Don Armstrong  https://www.donarmstrong.com

Those who begin coercive elimination of dissent soon find themselves
exterminating dissenters. Compulsory unification of opinion achieves
only the unanimity of the graveyard.
 -- Justice Roberts in 319 U.S. 624 (1943)

Re: Can't find the DNS Servers

[Michael Stone]

On Tue, Sep 26, 2017 at 03:43:35PM -0400, Greg Wooledge wrote:

NAME
resolver - resolver configuration file

SYNOPSIS
/etc/resolv.conf

...
search   Search list for host-name lookup.  The search list is normally
 determined from the local domain name; by default, it contains
 only the local domain name.  This may be changed by listing the
 desired domain search path following the search keyword with
 spaces or tabs separating the names.  Most resolver queries will
 be attempted using each component of the search path in turn un-
 til a match is found.  Note that this process may be slow and
 will generate a lot of network traffic if the servers for the
 listed domains are not local, and that queries will time out if
 no server is available for one of the domains.

 The search list is currently limited to six domains with a total
 of 256 characters.
...
4th Berkeley Distribution  November 11, 1993 1


I still think you're carrying along some mistake that you made decades
ago, which has simply never caused any problems, but is also not doing
anything beneficial.


This. Here's an extract from the oldest debian man page I know of for 
this file (from 1995--and people complain about how up to date the 
documentation is today!):


  domain Local domain name.  Most queries for  names  within
 this  domain  can  use  short names relative to the
 local domain.  If no domain entry is  present,  the
 domain  is  determined  from  the  local  host name
 returned by  gethostname(2);  the  domain  part  is
 taken   to  be  everything  after  the  first  `.'.
 Finally, if the host name does not contain a domain
 part, the root domain is assumed.

  search Search  list for host-name lookup.  The search list
 is normally determined from the local domain  name;
 by  default,  it begins with the local domain name,
 then successive parent domains that have  at  least
 two components in their names.  This may be changed
 by listing the desired domain search path following
 the  search  keyword with spaces or tabs separating
 the names.  Most resolver queries will be attempted

   December 14, 1989   1

RESOLVER(5)   RESOLVER(5)

 using  each  component  of  the search path in turn
 until a match is found.  Note that this process may
 be  slow and will generate a lot of network traffic
 if the servers  for  the  listed  domains  are  not
 local,  and that queries will time out if no server
 is available for one of the domains.

 The search list is currently limited to six domains
 with a total of 256 characters.

  The domain and search keywords are mutually exclusive.  If
  more than one instance of these keywords is  present,  the
  last instance will override.

The last paragraph is why it's just odd, not problematic. The current 
man page is basically identical.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Tue, Sep 26, 2017 at 03:19:51PM -0400, Gene Heskett wrote:
> > domain coyote.den
> 
> This I think is a leftover from when it was the place to put your 
> domainname, but now we've had the domainname utility to set that for 
> what, a decade?, and I could probably remove that line.  Belt and 
> suspenders I guess.  :)

The domainname(1) command is for NIS, not DNS.

The "domain" directive in resolv.conf is deprecated (maybe?) in favor of
the "search" list, but the latter is a list of domain names, not places
to consult.  (If "domain" is given and "search" is not, then "search"
uses the name that is in "domain" as its only entry.)

The list of places to consult for name resolution is in /etc/nsswitch.conf
in recent releases, and was in /etc/host.conf a very long time ago.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Tue, Sep 26, 2017 at 03:33:48PM -0400, Gene Heskett wrote:

> > > nameserver 192.168.XX.1
> > > search host dns
> > > domain coyote.den

> I started with Red Hat 5.0, in the late '90's. And it looks like stretch 
> may have deprecated the executable, locate can only find the  .conf 
> files, one in /etc, and one in  /usr/share/libc-bin/nsswitch.conf. Maybe 
> its something libc-bin uses? They are identical FWTW.

>From Red Hat 5.2 (Apollo) resolver(5):


NAME
 resolver - resolver configuration file

SYNOPSIS
 /etc/resolv.conf

...
 search   Search list for host-name lookup.  The search list is normally
  determined from the local domain name; by default, it contains
  only the local domain name.  This may be changed by listing the
  desired domain search path following the search keyword with
  spaces or tabs separating the names.  Most resolver queries will
  be attempted using each component of the search path in turn un-
  til a match is found.  Note that this process may be slow and
  will generate a lot of network traffic if the servers for the
  listed domains are not local, and that queries will time out if
  no server is available for one of the domains.

  The search list is currently limited to six domains with a total
  of 256 characters.
...
4th Berkeley Distribution  November 11, 1993 1


I still think you're carrying along some mistake that you made decades
ago, which has simply never caused any problems, but is also not doing
anything beneficial.  But if you can tell us *which* man page you saw
this in, that would be of interest.

P.S. there's nothing new in stretch here.  Even the wheezy man page for
resolv.conf(5) looks basically the same as stretch's.  Compare:

https://manpages.debian.org/wheezy/manpages/resolv.conf.5.en.html
https://manpages.debian.org/stretch/manpages/resolv.conf.5.en.html

Re: Can't find the DNS Servers

[Gene Heskett]

On Tuesday 26 September 2017 14:59:41 Greg Wooledge wrote:

> On Tue, Sep 26, 2017 at 01:42:39PM -0500, David Wright wrote:
> > On this topic, I still can't understand the contents of your
> > immutable /etc/resolv.conf file, even without the comma:
> >
> > nameserver 192.168.XX.1
> > search host dns
> > domain coyote.den
> >
> > Can you detail these domains called host and dns?
>
> I keep thinking that it's some relic from libc4 or libc5, before the
> adoption of nsswitch.conf, but I am at a loss how to find
> documentation that old to prove or disprove my guess.
>
> The nearest I could find is 
> which describes an /etc/host.conf file that contains "order bind
> hosts". I can't tell whether Gene's setup is an erroneous take on this
> obsolete configuration file (somehow merging it into resolv.conf), or
> something else entirely.  Perhaps something even older, or something
> from a non-Linux system.

I started with Red Hat 5.0, in the late '90's. And it looks like stretch 
may have deprecated the executable, locate can only find the  .conf 
files, one in /etc, and one in  /usr/share/libc-bin/nsswitch.conf. Maybe 
its something libc-bin uses? They are identical FWTW.


Cheers Greg, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[Gene Heskett]

On Tuesday 26 September 2017 14:42:39 David Wright wrote:

> On Mon 25 Sep 2017 at 18:41:33 (-0400), Gene Heskett wrote:
> > On Monday 25 September 2017 13:53:17 Greg Wooledge wrote:
> > > On Mon, Sep 25, 2017 at 07:32:05PM +0200, Pascal Hambourg wrote:
> > > > Le 25/09/2017 à 17:33, Gene Heskett a écrit :
> > > > > For me, its a root session, and a "chattr +i resolv.conf"
> > > >
> > > > Here we have a saying that roughly translates to :
> > > > "When you have a hammer, any problem looks like a nail."
> > >
> > > No.  Seriously, just stop.
> > >
> > > Those of us who have done chattr +i on one or more systems have,
> > > in many cases, TRIED OTHER SOLUTIONS first and found them wanting.
> > >
> > > Take me for example.
> > >
> > > At work, I edited /etc/dhcp/dhclient.conf and removed the options
> > > that tell dhclient to ask for domain-name-servers (et al.).  This
> > > works fine for me at work.  The DHCP servers at work respect my
> > > wish not to be given a domain-name-server, so dhclient never
> > > touches resolv.conf and everyone is happy.
> > >
> > > Then I tried the same thing at home.
> > >
> > > The results were NOT the same.
> > >
> > > The Belkin plastic router at home sends me a domain-name-server
> > > even if I do not ask for one.  And dhclient apparently overwrites
> > > resolv.conf every time it receives a domain-name-server from the
> > > DHCP server.
> > >
> > > EVEN IF IT DID NOT REQUEST ONE.
> > >
> > > So, the solution that I used at work does not work at home.
> > >
> > > You know what DOES work, though?
> > >
> > > chattr +i works.
> > >
> > > Do I prefer this solution?  No.
> > >
> > > Would I be happier if I could use a more elegant solution?  Yes.
> > >
> > > Should the dhclient program have a CONFIG FILE OPTION to say
> > > "NEVER TOUCH THE resolv.conf FILE"?  YES!
> > >
> > > Does it?  NO!
> > >
> > > Do I expect it ever to have one in the future?  BWA-hahahaha!  No.
> > >
> > > So we use what works, because the other choices don't fucking
> > > work.
> > >
> > > This is not about lack of creativity.
> > >
> > > It is not about being too blind or ignorant or stubborn to use the
> > > other solutions.  ("Everything looks like a nail.")
> > >
> > > This is about the other soluttions NOT WORKING.
> > >
> > > It is about ISC being too blind or ignorant or stubborn to
> > > consider that many people run the DHCP client software WITHOUT
> > > being the ones in charge of the DHCP server on the same network.
> > >
> > > Or, not considering that many people use cheap plastic
> > > consumer-grade routers that don't behave the same way the ISC DHCP
> > > server behaves.
> > >
> > > Am I getting through yet?
> >
> > I am with Greg on this one. And I HAVE tried everything the man
> > pages tell me, and it does NOT work, so I do what DOES WORK. 
> > Someday, maybe dhcpd will be smart enough to actually do what we
> > tell it to do.
> >
> > But that day hasn't even shown a cloud of dust on the time horizon I
> > can see from a 83 yo in <2 weeks viewpoint.
> >
> > Because all you so-called experts THINK it works  ok the way it is,
> > we get badmouthed and called idiots.  Bad dog, no biscuit, not even
> > the smell of one in an all static network situation.
>
> Well sometimes I wonder if we're using different tools, so I always
> treat your fixes with a great deal of salt. For example, I could
> bypass the partitioner in the Debian-installer, I couldn't make
> aptitude destroy my system by removing lots of packages without
> explicitly being told to, and I couldn't make   # passwd   demand
> the old password, to name a few examples.
>
> On this topic, I still can't understand the contents of your
> immutable /etc/resolv.conf file, even without the comma:
>
> nameserver 192.168.XX.1
> search host dns
"host" is a typu, s/b "hosts", which means it checks the /etc/hosts file 
for the name you typed, and if not found there it queries the local dns 
server at nameserver's address, which if its not in dd-wrt's name cache, 
gets forwarded to my isp's dns servers. Takes about an extra 50ms to 
resolve a name its not heard of in recent history.  And 100% transparent 
to me.

the dns is a synonym for nameserver, I have /etc/resolv.conf's using 
both, and while the man page says a "space separated" list of sources, I 
ran in my stupidity, resolv.conf's that had comma separated lists.  Work 
just fine for over 20 years.  Keywords "search" and "order" seem also to 
be interchangeable, and either is handled in the order given.

> domain coyote.den

This I think is a leftover from when it was the place to put your 
domainname, but now we've had the domainname utility to set that for 
what, a decade?, and I could probably remove that line.  Belt and 
suspenders I guess.  :)

> Can you detail these domains called host and dns?

See inline above.

> Cheers,
> David.

Cheers David, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in 

Re: Can't find the DNS Servers

[Gene Heskett]

On Tuesday 26 September 2017 13:51:33 David Wright wrote:

> On Mon 25 Sep 2017 at 17:32:28 (-0400), Gene Heskett wrote:
> > > On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote:
> > > > For me, its a root session, and a "chattr +i resolv.conf"
> > > > If for some reason you need to edit it later, you'll have to use
> > > > the -i argument first. As long as that +i bit is set, its
> > > > protected from everything but a mke2fs.
> >
> > Unforch, this isn't /root stuffs, but /etc stuffs.  And it works.
> > And I could care less how disappointed n-m or dhcpd is.  Or even
> > resolvconf itself. Particularly when its as buggy as a 10 day old
> > road kill in August.
> >
> > Yes, there is a place for dhcp, but its for sure not on a home,
> > small number of machines network thats all static.
>
> I don't recognise this as a very frequent use case nowadays, with
> so many laptops etc.

Probably true, but the lappy I bought for while I was out playing 
consultant after I retired, which put me in a motel or the owner guest 
house for months at a time for several years, is now quite aged and 
hasn't been powered up in several months for anything but updates to its 
mint 15 install.  So I could be the exception to that "rule".

> So for simplicity, I configure my laptops and 
> desktops alike, with wicd, dhcp and resolvconf. I put hostnames, MACs,
> and static nameservers' addresses into the "cheap plastic
> consumer-grade router" (which has no DNS server) because that doesn't
> travel anywhere,

And in turn that cheap plastic consumer grade router no doubt has an NSA 
back door clear into the smallest machine on your network.  My router is 
a plastic buffalo netfinity, paid about $70 for it and it has been 
reflashed with the real dd-wrt, not the version that it came with, which 
among many other features has a dhcp client to get its address from my 
isp, but it also has a server that can if configured to do so, hand out 
200 some leases.  It also has no back doors for the NSA, and in 15 years 
of running dd-wrt on 3 different pieces of hardware, has had only one 
person come thru it and I gave him the username and pw to do so.
Lots of features I don't enable are there. Port forwarding is one, you 
can see my web page (in the sig) which I run in a sandbox on this 
machine.

> and /etc/hosts looks after LAN addresses. And if I 
> want to do fast bulk transfers between machines in the same room,
> I connect a cat5 cable and use the IPv6 addresses to avoid disturbing
> the normal networking through the router.

I'll have to plead ipv6 ignorance as the nearest outside ipv6 is at least 
100 miles away from me. My questions as to how to enable it between the 
10 or so ipv4 addresses available here if everything is booted up, have 
been ignored. I don't know if the first of two switches I have here even 
passes it, and haven't seen a "getting started with ipv6 for dummies" 
tutorial, if it even exists.

I suspect it will arrive here after I've not made morning roll call for 
several years.  So like a jar of pickles I found while cleaning out the 
veggie drawer today, its been shoved to the back of the bottom shelf. :)

But you should get yourself a real router, and reflash it with some real 
router firmware, dd-wrt, tomato or one of the other lesser known router 
firmwares. dd-wrt is bulletproof to the point I don't run iptables or 
its ilk on the machines of my local network.  Don't need it.

> Cheers,
> David.

You too, David.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[Greg Wooledge]

On Tue, Sep 26, 2017 at 01:42:39PM -0500, David Wright wrote:
> On this topic, I still can't understand the contents of your
> immutable /etc/resolv.conf file, even without the comma:
> 
> nameserver 192.168.XX.1
> search host dns
> domain coyote.den
> 
> Can you detail these domains called host and dns?

I keep thinking that it's some relic from libc4 or libc5, before the
adoption of nsswitch.conf, but I am at a loss how to find documentation
that old to prove or disprove my guess.

The nearest I could find is 
which describes an /etc/host.conf file that contains "order bind hosts".
I can't tell whether Gene's setup is an erroneous take on this obsolete
configuration file (somehow merging it into resolv.conf), or something
else entirely.  Perhaps something even older, or something from a
non-Linux system.

Re: Can't find the DNS Servers

[David Wright]

On Mon 25 Sep 2017 at 18:41:33 (-0400), Gene Heskett wrote:
> On Monday 25 September 2017 13:53:17 Greg Wooledge wrote:
> 
> > On Mon, Sep 25, 2017 at 07:32:05PM +0200, Pascal Hambourg wrote:
> > > Le 25/09/2017 à 17:33, Gene Heskett a écrit :
> > > > For me, its a root session, and a "chattr +i resolv.conf"
> > >
> > > Here we have a saying that roughly translates to :
> > > "When you have a hammer, any problem looks like a nail."
> >
> > No.  Seriously, just stop.
> >
> > Those of us who have done chattr +i on one or more systems have, in
> > many cases, TRIED OTHER SOLUTIONS first and found them wanting.
> >
> > Take me for example.
> >
> > At work, I edited /etc/dhcp/dhclient.conf and removed the options that
> > tell dhclient to ask for domain-name-servers (et al.).  This works
> > fine for me at work.  The DHCP servers at work respect my wish not to
> > be given a domain-name-server, so dhclient never touches resolv.conf
> > and everyone is happy.
> >
> > Then I tried the same thing at home.
> >
> > The results were NOT the same.
> >
> > The Belkin plastic router at home sends me a domain-name-server even
> > if I do not ask for one.  And dhclient apparently overwrites
> > resolv.conf every time it receives a domain-name-server from the DHCP
> > server.
> >
> > EVEN IF IT DID NOT REQUEST ONE.
> >
> > So, the solution that I used at work does not work at home.
> >
> > You know what DOES work, though?
> >
> > chattr +i works.
> >
> > Do I prefer this solution?  No.
> >
> > Would I be happier if I could use a more elegant solution?  Yes.
> >
> > Should the dhclient program have a CONFIG FILE OPTION to say
> > "NEVER TOUCH THE resolv.conf FILE"?  YES!
> >
> > Does it?  NO!
> >
> > Do I expect it ever to have one in the future?  BWA-hahahaha!  No.
> >
> > So we use what works, because the other choices don't fucking work.
> >
> > This is not about lack of creativity.
> >
> > It is not about being too blind or ignorant or stubborn to use the
> > other solutions.  ("Everything looks like a nail.")
> >
> > This is about the other soluttions NOT WORKING.
> >
> > It is about ISC being too blind or ignorant or stubborn to consider
> > that many people run the DHCP client software WITHOUT being the ones
> > in charge of the DHCP server on the same network.
> >
> > Or, not considering that many people use cheap plastic consumer-grade
> > routers that don't behave the same way the ISC DHCP server behaves.
> >
> > Am I getting through yet?
> 
> I am with Greg on this one. And I HAVE tried everything the man pages 
> tell me, and it does NOT work, so I do what DOES WORK.  Someday, maybe 
> dhcpd will be smart enough to actually do what we tell it to do.
> 
> But that day hasn't even shown a cloud of dust on the time horizon I can 
> see from a 83 yo in <2 weeks viewpoint.
> 
> Because all you so-called experts THINK it works  ok the way it is, we 
> get badmouthed and called idiots.  Bad dog, no biscuit, not even the 
> smell of one in an all static network situation.

Well sometimes I wonder if we're using different tools, so I always
treat your fixes with a great deal of salt. For example, I could
bypass the partitioner in the Debian-installer, I couldn't make
aptitude destroy my system by removing lots of packages without
explicitly being told to, and I couldn't make   # passwd   demand
the old password, to name a few examples.

On this topic, I still can't understand the contents of your
immutable /etc/resolv.conf file, even without the comma:

nameserver 192.168.XX.1
search host dns
domain coyote.den

Can you detail these domains called host and dns?

Cheers,
David.

Re: Can't find the DNS Servers

[David Wright]

On Mon 25 Sep 2017 at 17:32:28 (-0400), Gene Heskett wrote:

> > On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote:
> > > For me, its a root session, and a "chattr +i resolv.conf"
> > > If for some reason you need to edit it later, you'll have to use the
> > > -i argument first. As long as that +i bit is set, its protected from
> > > everything but a mke2fs.
> 
> Unforch, this isn't /root stuffs, but /etc stuffs.  And it works. And I 
> could care less how disappointed n-m or dhcpd is.  Or even resolvconf 
> itself. Particularly when its as buggy as a 10 day old road kill in 
> August.
> 
> Yes, there is a place for dhcp, but its for sure not on a home, small 
> number of machines network thats all static.

I don't recognise this as a very frequent use case nowadays, with
so many laptops etc. So for simplicity, I configure my laptops and
desktops alike, with wicd, dhcp and resolvconf. I put hostnames, MACs,
and static nameservers' addresses into the "cheap plastic
consumer-grade router" (which has no DNS server) because that doesn't
travel anywhere, and /etc/hosts looks after LAN addresses. And if I
want to do fast bulk transfers between machines in the same room,
I connect a cat5 cable and use the IPv6 addresses to avoid disturbing
the normal networking through the router.

Cheers,
David.

Re: Can't find the DNS Servers

[Gene Heskett]

On Tuesday 26 September 2017 11:30:48 Michael Stone wrote:

> On Tue, Sep 26, 2017 at 11:21:35AM -0400, Gene Heskett wrote:
> >I'll give you the ip man page as another perfect example. I've never
> >read a more obtuse manpage in my life. I get the impression the
> > manpage writer is charged 10 dollars a word for emmiting anything
> > over 100 words.
> >
> >The whole man pages tree on the install I am currently doing is 13
> >megabytes.  The sd card its on is 32 gigabytes, so we'll have at
> > least 10 gigabytes we could use for man pages without impacting its
> > ability to store and use a 300 kilobyte package, if they were just
> > written to teach us what to do.
>
> If you aren't volunteering to write the man pages, could you at least
> tone down the rhetoric and find a way to express your concerns without
> the name calling and insulting characterizations?
>
> Mike Stone

I am not calling out a specific authors name, but as Johnny Carson once 
said in paraphrasing words if the foo shits, wear it.

Looking at the overall picture vis-a-vis man pages, I call 'em like I 
see 'em. Remaining life to enjoy a well written manpage or pinfo output, 
for me is too short to do otherwise. I've had my 4 score + a few years 
already.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Sep 26, 2017 at 11:30:48AM -0400, Michael Stone wrote:

[...]

> If you aren't volunteering to write the man pages, could you at
> least tone down the rhetoric and find a way to express your concerns
> without the name calling and insulting characterizations?

Thankyou.

- -- t
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnKdBUACgkQBcgs9XrR2kb/jACdFB+v3ppXa1sZXhEtTRloqYUH
0AYAn0Dcx12s+iPuaN+J0Zm73zKXwVeT
=Cf+p
-END PGP SIGNATURE-

Re: Can't find the DNS Servers

[Gene Heskett]

On Tuesday 26 September 2017 10:04:42 Darac Marjal wrote:

> On Tue, Sep 26, 2017 at 09:09:47AM -0400, Greg Wooledge wrote:
> >On Mon, Sep 25, 2017 at 02:12:07PM -0700, Don Armstrong wrote:
> >> On Mon, 25 Sep 2017, Greg Wooledge wrote:
> >> > On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> >> > > as is documented in dhclient-script(8):
> >> >
> >> > Well now that's just EVIL. :-(
> >>
> >> It's much more powerful than a single variable because you can have
> >> it do *anything*.
> >
> >No, you don't understand.  I had no idea that man page EXISTED!
> >For years, I have been searching back and forth and up and down in
> >dhclient(8) and dhclient.conf(5) and finding NOTHING.
> >
> >Turns out the REASON I couldn't find anything was because some bright
> >spark decided to split the documentation into multiple man pages.
> >
> >> > Well now that's just EVIL. :-(
> >
> >So, apparently the only way to find anything is to open umpteen
> > terminal windows, one man page in each terminal window.  Jump to the
> > bottom of each man page, find the SEE ALSO section, open EVERY
> > linked man page in another terminal window.  Recursively.  Then
> > perform your searches in every single window in parallel until one
> > of them hits.
>
> [cut]
>
> >All this grief and agony because they couldn't just put all the
> >information that THE MOST COMMON USE CASES will need into a single
> >document.
>
> [tl;dr]
>
> I think you might be under a misconception about what man pages are
> FOR.
>
> From the first few lines of "man man":
>
>man - an interface to the on-line reference manuals
>
> They are *reference* manuals. I believe that the point of man pages is
> to answer questions such as:
>
>  * What's the option for filtering out files: --filter or --exclude
>  * What was that weird option for doing something dangerous
>"DoWhatIWant"... "YesIReallyMeanThis"... something like that.
>  * Can I perform this action recursively?
>
> As a result, man pages are usually little more than lists of command
> line parameters which explanations of what they do.
>
> What man pages generally DON'T cover are:
>
>  * How do I use this program for X?
>  * Why do I need this program?
>  * What the difference between this program and that program?
>  * How do I use this program with that program?
>
>  The GNU solution to that was the 'info' system. 'info' is a
> hyperlinked text format - a bit like having a web site on your
> computer. Look at the info page for grub, as an example: the
> information is grouped by topic, there's obscure things like
> limitations on the core size per platform and so on.
>
>  It's just a pity that most programs don't provide info pages.

Ditto the more intelligent yet, pinfo.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[Michael Stone]

On Tue, Sep 26, 2017 at 11:21:35AM -0400, Gene Heskett wrote:
I'll give you the ip man page as another perfect example. I've never 
read a more obtuse manpage in my life. I get the impression the manpage 
writer is charged 10 dollars a word for emmiting anything over 100 
words.


The whole man pages tree on the install I am currently doing is 13
megabytes.  The sd card its on is 32 gigabytes, so we'll have at least
10 gigabytes we could use for man pages without impacting its ability to
store and use a 300 kilobyte package, if they were just written to teach
us what to do.


If you aren't volunteering to write the man pages, could you at least 
tone down the rhetoric and find a way to express your concerns without 
the name calling and insulting characterizations?


Mike Stone

Re: Can't find the DNS Servers

[Gene Heskett]

On Tuesday 26 September 2017 09:09:47 Greg Wooledge wrote:

> On Mon, Sep 25, 2017 at 02:12:07PM -0700, Don Armstrong wrote:
> > On Mon, 25 Sep 2017, Greg Wooledge wrote:
> > > On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> > > > as is documented in dhclient-script(8):
> > >
> > > Well now that's just EVIL. :-(
> >
> > It's much more powerful than a single variable because you can have
> > it do *anything*.
>
> No, you don't understand.  I had no idea that man page EXISTED!
> For years, I have been searching back and forth and up and down in
> dhclient(8) and dhclient.conf(5) and finding NOTHING.
>
> Turns out the REASON I couldn't find anything was because some bright
> spark decided to split the documentation into multiple man pages.
>
> > > Well now that's just EVIL. :-(
>
> So, apparently the only way to find anything is to open umpteen
> terminal windows, one man page in each terminal window.  Jump to the
> bottom of each man page, find the SEE ALSO section, open EVERY linked
> man page in another terminal window.  Recursively.  Then perform your
> searches in every single window in parallel until one of them hits.
>
> So let's see... I'll assume dhclient(8) is the root of the search
> tree.  This links to dhcpd(8), dhcrelay(8), dhclient-script(8),
> dhclient.conf(5), dhclient.leases(5), dhcp-eval(5).  So now I need
> to open 6 more windows, or 7 total.
>
> dhcpd(8) doesn't exist, because this isn't a server, so make it 6.
>
> dhcrelay(8) doesn't exist.  Don't even know what that is.  5.
>
> dhclient-script(8) links to dhclient(8), dhcpd(8), dhcrelay(8),
> dhclient.conf(5), dhclient.leases(5).  No new windows.
>
> dhclient.conf(5) links to dhcp-options(5), dhcp-eval(5),
> dhclient.leases(5), dhcpd(8), dhcpd.conf(5).  dhcpd.conf(5) doesn't
> exist, so just one new window, for dhcp-options(5).  I'm up to 6 open
> now.
>
> dhclient.leases(5) links to dhclient(8), dhcp-options(5),
> dhclient.conf(5), dhcpd(8), dhcpd.conf(5).  No new ones.
>
> dhcp-eval(5) links to dhcpd.conf(5), dhcpd.leases(5),
> dhclient.conf(5), dhcp-options(5), dhcpd(8), dhclient(8). 
> dhcpd.leases(5) doesn't exist, so no new ones.
>
> dhcp-options(5) links to dhcpd.conf(5), dhcpd.leases(5),
> dhclient.conf(5), dhcp-eval(5), dhcpd(8), dhclient(8).  No new ones.
>
> So I've got my 6 terminal windows open.  I've spent 10 minutes so far,
> and I haven't even READ a single bit of any of the pages.  Just the
> SEE ALSOs.
>
> Now I get to try to wrack my brain for keywords, and repeat my keyword
> searches 6 times, once in every window.
>
> Turns out "resolv" (my first keyword) pops up in window #2, which is
> dhclient-script(8), and also in window #6, dhcp-options(5).
>
> From there, you can guess what the next steps are, because apparently
> you were already aware of the existence of dhclient-script(8).  If I'm
> lucky, I'll focus on that page rather than dhcp-options(5) which is
> very confusing, and seems to be talking in abstractions.  It sure as
> hell doesn't clearly define what options go in what files, nor even
> which options are for the client and which are for the server.  Their
> only mentions of resolv.conf are in a DHCPV6 section.  What the hell
> is DHCPV6?  Does it have something to do with IPv6?  How would I know
> whether I'm using DHCPV6 or not?  Try searching for V6 in the other
> five windows... nothing at all!  And so on.
>
> All this grief and agony because they couldn't just put all the
> information that THE MOST COMMON USE CASES will need into a single
> document.
>
> What are the most common use cases?  An excellent question.  Here's
> my guess:
>
> 1) Client is plugged into the network without being configured. 
> Simply uses whatever the DHCP server spits out.  If that's wrong, too
> bad.
>
> 2) Client uses what the DHCP server spits out, but the administrator
>of the client will try to work around whichever bits of the DHCP
>server's responses are wrong.  In my experience, it's the
> nameservers that are most likely to need local adjustment.  That's why
> you have this thread.  And all the previous threads.  And all the web
> pages out there that advise people to use chattr +i.  And all the
> people who use chattr +i.  And all the self-proclaimed experts who say
> "No, you're doing it wrong!" but then don't offer a better way.
>
> 3) Client uses what the DHCP server spits out, but the administrator
>of the client is also the administrator of the DHCP server, and can
>correct things in the DHCP server to make all the clients happy.
>
> The first use case needs no documentation at all.
>
> The second use case needs some way for the admin of the client to be
> able to search for resolv.conf in the documentation and actually FIND
> IT. I searched in dhclient(8) and in dhclient.conf(5) and fid not find
> it. I honestly, truly believed that I had done my best.  That I had
> put in the required effort.  That I had been intelligent and diligent
> and resourceful.  That I had given 

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 26/09/2017 à 15:09, Greg Wooledge a écrit :


lucky, I'll focus on that page rather than dhcp-options(5) which is
very confusing, and seems to be talking in abstractions.  It sure as
hell doesn't clearly define what options go in what files, nor even
which options are for the client and which are for the server.


dhcp-options(5) describes options of the DHCP protocol itself, so they 
apply to both clients and servers.



Their
only mentions of resolv.conf are in a DHCPV6 section.  What the hell
is DHCPV6?  Does it have something to do with IPv6?


Yes, DHCPv6 is the IPv6 version of DHCP.


How would I know whether I'm using DHCPV6 or not?


Tough question. It depends on how you configure your network interfaces, 
with /etc/network/interfaces, NetworkManager or whatever...


I do not use it because I am satisfied with the simpler IPv6 stateless 
auto-configuration (SLAAC) protocol on the client stations, and static 
IPv6 configuration on the servers.

Re: Can't find the DNS Servers

[Darac Marjal]

On Tue, Sep 26, 2017 at 09:09:47AM -0400, Greg Wooledge wrote:

On Mon, Sep 25, 2017 at 02:12:07PM -0700, Don Armstrong wrote:

On Mon, 25 Sep 2017, Greg Wooledge wrote:
> On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> > as is documented in dhclient-script(8):
>
> Well now that's just EVIL. :-(

It's much more powerful than a single variable because you can have it
do *anything*.


No, you don't understand.  I had no idea that man page EXISTED!
For years, I have been searching back and forth and up and down in
dhclient(8) and dhclient.conf(5) and finding NOTHING.

Turns out the REASON I couldn't find anything was because some bright
spark decided to split the documentation into multiple man pages.


> Well now that's just EVIL. :-(


So, apparently the only way to find anything is to open umpteen terminal
windows, one man page in each terminal window.  Jump to the bottom of
each man page, find the SEE ALSO section, open EVERY linked man page in
another terminal window.  Recursively.  Then perform your searches in
every single window in parallel until one of them hits.


[cut]


All this grief and agony because they couldn't just put all the
information that THE MOST COMMON USE CASES will need into a single
document.


[tl;dr]

I think you might be under a misconception about what man pages are FOR.

From the first few lines of "man man":

 man - an interface to the on-line reference manuals

They are *reference* manuals. I believe that the point of man pages is 
to answer questions such as:


* What's the option for filtering out files: --filter or --exclude
* What was that weird option for doing something dangerous 
  "DoWhatIWant"... "YesIReallyMeanThis"... something like that.

* Can I perform this action recursively?

As a result, man pages are usually little more than lists of command 
line parameters which explanations of what they do.


What man pages generally DON'T cover are:

* How do I use this program for X?
* Why do I need this program?
* What the difference between this program and that program?
* How do I use this program with that program?

The GNU solution to that was the 'info' system. 'info' is a hyperlinked 
text format - a bit like having a web site on your computer. Look at 
the info page for grub, as an example: the information is grouped by 
topic, there's obscure things like limitations on the core size per 
platform and so on.


It's just a pity that most programs don't provide info pages.

--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Can't find the DNS Servers

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Sep 26, 2017 at 09:09:47AM -0400, Greg Wooledge wrote:

[...]

> No, you don't understand.  I had no idea that man page EXISTED!
> For years, I have been searching back and forth and up and down in
> dhclient(8) and dhclient.conf(5) and finding NOTHING.
> 
> Turns out the REASON I couldn't find anything was because some bright
> spark decided to split the documentation into multiple man pages.

To be fair, dhclient-script is figures in the output of

  man -k dhclient

And is mentioned several times in the dhclient man page (in the see-also
section, among other things).

> So let's see... I'll assume dhclient(8) is the root of the search
> tree.  This links to dhcpd(8), dhcrelay(8), dhclient-script(8),
> dhclient.conf(5), dhclient.leases(5), dhcp-eval(5).  So now I need
> to open 6 more windows, or 7 total.

Dhclient-script is also ref'd to from dhclient-conf(5). Alas, not in
the "see-also" section (IMHO it should be).

I know this would be preaching to the choir for the ones and lost on
the others -- but do give Emacs' WoMan mode a try. It is Emacs' man
page viewer, and does a good job of making clickable links of all
those embedded refs. Hypertext! (I know, I know: another story started
like this one and isn't ending well, but... ;-)

Don't get me wrong: it happens to me all the time that it's there,
in front of my nose, and I don't see it. I take this as a chance
to ask myself: "how would I have done that, as a writer, to help
my other self? how can I, as a reader, be smarter next time?)

Doumentation Is Hard (TM)

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnKWbcACgkQBcgs9XrR2kbTKwCcCrVDUK3riaKtJ2vW7mTrxH2l
JZgAn1yjHGVLAtXNiHpD1Temy+QaV1dp
=LLxs
-END PGP SIGNATURE-

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 02:12:07PM -0700, Don Armstrong wrote:
> On Mon, 25 Sep 2017, Greg Wooledge wrote:
> > On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> > > as is documented in dhclient-script(8):
> > 
> > Well now that's just EVIL. :-(
> 
> It's much more powerful than a single variable because you can have it
> do *anything*.

No, you don't understand.  I had no idea that man page EXISTED!
For years, I have been searching back and forth and up and down in
dhclient(8) and dhclient.conf(5) and finding NOTHING.

Turns out the REASON I couldn't find anything was because some bright
spark decided to split the documentation into multiple man pages.

> > Well now that's just EVIL. :-(

So, apparently the only way to find anything is to open umpteen terminal
windows, one man page in each terminal window.  Jump to the bottom of
each man page, find the SEE ALSO section, open EVERY linked man page in
another terminal window.  Recursively.  Then perform your searches in
every single window in parallel until one of them hits.

So let's see... I'll assume dhclient(8) is the root of the search
tree.  This links to dhcpd(8), dhcrelay(8), dhclient-script(8),
dhclient.conf(5), dhclient.leases(5), dhcp-eval(5).  So now I need
to open 6 more windows, or 7 total.

dhcpd(8) doesn't exist, because this isn't a server, so make it 6.

dhcrelay(8) doesn't exist.  Don't even know what that is.  5.

dhclient-script(8) links to dhclient(8), dhcpd(8), dhcrelay(8),
dhclient.conf(5), dhclient.leases(5).  No new windows.

dhclient.conf(5) links to dhcp-options(5), dhcp-eval(5),
dhclient.leases(5), dhcpd(8), dhcpd.conf(5).  dhcpd.conf(5) doesn't exist,
so just one new window, for dhcp-options(5).  I'm up to 6 open now.

dhclient.leases(5) links to dhclient(8), dhcp-options(5), dhclient.conf(5),
dhcpd(8), dhcpd.conf(5).  No new ones.

dhcp-eval(5) links to dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5),
dhcp-options(5), dhcpd(8), dhclient(8).  dhcpd.leases(5) doesn't exist,
so no new ones.

dhcp-options(5) links to dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5),
dhcp-eval(5), dhcpd(8), dhclient(8).  No new ones.

So I've got my 6 terminal windows open.  I've spent 10 minutes so far,
and I haven't even READ a single bit of any of the pages.  Just the
SEE ALSOs.

Now I get to try to wrack my brain for keywords, and repeat my keyword
searches 6 times, once in every window.

Turns out "resolv" (my first keyword) pops up in window #2, which is
dhclient-script(8), and also in window #6, dhcp-options(5).

>From there, you can guess what the next steps are, because apparently
you were already aware of the existence of dhclient-script(8).  If I'm
lucky, I'll focus on that page rather than dhcp-options(5) which is
very confusing, and seems to be talking in abstractions.  It sure as
hell doesn't clearly define what options go in what files, nor even
which options are for the client and which are for the server.  Their
only mentions of resolv.conf are in a DHCPV6 section.  What the hell
is DHCPV6?  Does it have something to do with IPv6?  How would I know
whether I'm using DHCPV6 or not?  Try searching for V6 in the other
five windows... nothing at all!  And so on.

All this grief and agony because they couldn't just put all the
information that THE MOST COMMON USE CASES will need into a single
document.

What are the most common use cases?  An excellent question.  Here's
my guess:

1) Client is plugged into the network without being configured.  Simply
   uses whatever the DHCP server spits out.  If that's wrong, too bad.

2) Client uses what the DHCP server spits out, but the administrator
   of the client will try to work around whichever bits of the DHCP
   server's responses are wrong.  In my experience, it's the nameservers
   that are most likely to need local adjustment.  That's why you have
   this thread.  And all the previous threads.  And all the web pages
   out there that advise people to use chattr +i.  And all the people
   who use chattr +i.  And all the self-proclaimed experts who say "No,
   you're doing it wrong!" but then don't offer a better way.
   
3) Client uses what the DHCP server spits out, but the administrator
   of the client is also the administrator of the DHCP server, and can
   correct things in the DHCP server to make all the clients happy.

The first use case needs no documentation at all.

The second use case needs some way for the admin of the client to be able
to search for resolv.conf in the documentation and actually FIND IT.
I searched in dhclient(8) and in dhclient.conf(5) and fid not find it.
I honestly, truly believed that I had done my best.  That I had put
in the required effort.  That I had been intelligent and diligent and
resourceful.  That I had given the software the benefit of the doubt,
but this feature was simply not present, or not documented anywhere.

The third use case... well, that's not me right now.  In the past I
have set up a DHCP server on an OpenBSD 

Re: Can't find the DNS Servers

[Reco]

Hi.

On Mon, Sep 25, 2017 at 12:49:22PM -0700, Gary Roach wrote:
> On 09/23/2017 09:31 PM, Cindy-Sue Causey wrote:
> > On 9/23/17, Gary Roach  wrote:
> > > Hi all.
> > > I have been trying for several day to get firefox to work on a newly
> > > installed Debian Stretch system. It Seems that Firefox can't find a DNS
> > > server. I am having the same problem with apt-get update. None of my
> > > mirrors can be reached. Ping works just fine. I can't even reach the
> > > other computers on my home network if I use their names. IP addresses
> > > work OK. I have installed resolvconf and followed several installation
> > > instructions to no avail. The name servers for my router
> > > (192.168.1.1)and both google servers at 8.8.8.8 and 8.8.4.4. are listed
> > > in the correct file (can't remember which one). This system worked fine
> > > when first installed. I installed qemu-kvm on the system and I think in
> > > broke things.I've run out of ideas.
> > > 
> > > Please help
> > 
> An addition is necessary here. The problem started when I installed the
> qemu-kvm virtual machine. Now the Kubuntu system - the guest - network
> access works fine. But the host machine can't find the DNS servers. This
> makes no sense.

And it never make any sense unless you troubleshoot it.

Please post these things from the problematic PC:

ip a l

ip ro l

cat /etc/resolv.conf

"tcpdump -nvi any udp port 53 or tcp port 53" run while doing
"getent hosts www.google.com"

Reco

Re: Can't find the DNS Servers

[Celejar]

On Mon, 25 Sep 2017 08:56:54 -0400
Greg Wooledge  wrote:

> On Sat, Sep 23, 2017 at 06:03:12PM -0700, Gary Roach wrote:

...

> > I have
> > installed resolvconf 
> 
> *shudder*
> 
> I mean, unless this is a laptop or a tablet or a phone or something.
> Then it may be appropriate, because you might actually WANT your
> resolv.conf file to be rewritten every time the wind changes direction.
> 
> For desktop machines with a static internal network configuration, it's
> an abomination.  And unfortunately it's not the only malevolent fiend
> trying to usurp control of your resolv.conf file.  There's also dhclient,
> and network-manager, and systemd-resolved, and who knows what else.

Just to clarify, on my laptop, I do want resolvconf installed, since
when I'm on my home LAN, I want to use the DNS server running on the
local router / gateway, and when I'm anywhere else, I want to use the
ISP's nameservers. With resolvconf, I add a "dns-nameservers
nnn.nnn.nnn.nnn" line to the LAN section of /etc/network/interfaces to
accomplish this via resolvconf.

Celejar

Re: Can't find the DNS Servers

[Gene Heskett]

On Monday 25 September 2017 13:53:17 Greg Wooledge wrote:

> On Mon, Sep 25, 2017 at 07:32:05PM +0200, Pascal Hambourg wrote:
> > Le 25/09/2017 à 17:33, Gene Heskett a écrit :
> > > For me, its a root session, and a "chattr +i resolv.conf"
> >
> > Here we have a saying that roughly translates to :
> > "When you have a hammer, any problem looks like a nail."
>
> No.  Seriously, just stop.
>
> Those of us who have done chattr +i on one or more systems have, in
> many cases, TRIED OTHER SOLUTIONS first and found them wanting.
>
> Take me for example.
>
> At work, I edited /etc/dhcp/dhclient.conf and removed the options that
> tell dhclient to ask for domain-name-servers (et al.).  This works
> fine for me at work.  The DHCP servers at work respect my wish not to
> be given a domain-name-server, so dhclient never touches resolv.conf
> and everyone is happy.
>
> Then I tried the same thing at home.
>
> The results were NOT the same.
>
> The Belkin plastic router at home sends me a domain-name-server even
> if I do not ask for one.  And dhclient apparently overwrites
> resolv.conf every time it receives a domain-name-server from the DHCP
> server.
>
> EVEN IF IT DID NOT REQUEST ONE.
>
> So, the solution that I used at work does not work at home.
>
> You know what DOES work, though?
>
> chattr +i works.
>
> Do I prefer this solution?  No.
>
> Would I be happier if I could use a more elegant solution?  Yes.
>
> Should the dhclient program have a CONFIG FILE OPTION to say
> "NEVER TOUCH THE resolv.conf FILE"?  YES!
>
> Does it?  NO!
>
> Do I expect it ever to have one in the future?  BWA-hahahaha!  No.
>
> So we use what works, because the other choices don't fucking work.
>
> This is not about lack of creativity.
>
> It is not about being too blind or ignorant or stubborn to use the
> other solutions.  ("Everything looks like a nail.")
>
> This is about the other soluttions NOT WORKING.
>
> It is about ISC being too blind or ignorant or stubborn to consider
> that many people run the DHCP client software WITHOUT being the ones
> in charge of the DHCP server on the same network.
>
> Or, not considering that many people use cheap plastic consumer-grade
> routers that don't behave the same way the ISC DHCP server behaves.
>
> Am I getting through yet?

I am with Greg on this one. And I HAVE tried everything the man pages 
tell me, and it does NOT work, so I do what DOES WORK.  Someday, maybe 
dhcpd will be smart enough to actually do what we tell it to do.

But that day hasn't even shown a cloud of dust on the time horizon I can 
see from a 83 yo in <2 weeks viewpoint.

Because all you so-called experts THINK it works  ok the way it is, we 
get badmouthed and called idiots.  Bad dog, no biscuit, not even the 
smell of one in an all static network situation.

Something that I have been dealing with on a daily basis now for 
something like 24 years at a tv station as its CE. We were, I think, the 
first tv station in the US to have a web page, folks had to dial it up 
for the first 6 months. Then we bought a block of 16 addresses, and a 
56k line, and put the amiga that served it on one of the addresses. Jim 
and I wrote that web server in ARexx.

If you want to be called an expert, first go fix dhcpd. Or n-m, but it 
likely uses dhcpd to do its damage. Then ask to be called an expert.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[Gene Heskett]

On Monday 25 September 2017 12:10:10 Reco wrote:

>   Hi.
>
> On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote:
> > > I mean, unless this is a laptop or a tablet or a phone or
> > > something. Then it may be appropriate, because you might actually
> > > WANT your resolv.conf file to be rewritten every time the wind
> > > changes direction.
> > >
> > > For desktop machines with a static internal network configuration,
> > > it's an abomination.  And unfortunately it's not the only
> > > malevolent fiend trying to usurp control of your resolv.conf file.
> > >  There's also dhclient, and network-manager, and systemd-resolved,
> > > and who knows what else.
> > >
> > > See 
> > > for some of your options.  Of course, before you can apply any of
> > > those suggestions, you have to seize back control of your
> > > resolv.conf file in the first place.  Make sure it's a FILE and
> > > not a symlink, and put the correct content into it.  Make sure
> > > name resolution works.  Then choose your favorite solution to keep
> > > the file under YOUR control.
> >
> > For me, its a root session, and a "chattr +i resolv.conf"
> > If for some reason you need to edit it later, you'll have to use the
> > -i argument first. As long as that +i bit is set, its protected from
> > everything but a mke2fs.
>
> A common misconception. Here's how a determined userspace can beat
> immutable bit:
>
> # mkdir testetc
> # touch testetc/resolv.conf
> # chattr +i testetc/resolv.conf
> # mv testetc/ testetc.orig
> # mkdir testetc
> # touch testetc/resolv.conf
> # echo evil dns > testetc/resolv.conf
>
> Of course you could try to counter that with "chattr +i /etc", but
> doing *that* should break an unimaginable number of things.
>
> If you really need immutable /etc/resolv.conf you should try the
> Read-Only Root Debian - [1].
>
> [1] https://wiki.debian.org/ReadonlyRoot
>
> Reco

Unforch, this isn't /root stuffs, but /etc stuffs.  And it works. And I 
could care less how disappointed n-m or dhcpd is.  Or even resolvconf 
itself. Particularly when its as buggy as a 10 day old road kill in 
August.

Yes, there is a place for dhcp, but its for sure not on a home, small 
number of machines network thats all static.
 

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[Don Armstrong]

On Mon, 25 Sep 2017, Greg Wooledge wrote:
> On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> > as is documented in dhclient-script(8):
> 
> Well now that's just EVIL. :-(

It's much more powerful than a single variable because you can have it
do *anything*.

But since most people don't care about that power, resolvconf is a much
better method to use to manage resolv.conf than chattr or any of the
other hacks. It does the right thing in almost every case and has hooks
for dhclient, NetworkManger, pppd, ifupdown, dnsmasq, etc.

-- 
Don Armstrong  https://www.donarmstrong.com

2: There is no out. There is only in.
  -- "The Prisoner (2009 Miniseries)"

Re: Can't find the DNS Servers

[Gary Roach]

On 09/23/2017 09:31 PM, Cindy-Sue Causey wrote:

On 9/23/17, Gary Roach  wrote:

Hi all.
I have been trying for several day to get firefox to work on a newly
installed Debian Stretch system. It Seems that Firefox can't find a DNS
server. I am having the same problem with apt-get update. None of my
mirrors can be reached. Ping works just fine. I can't even reach the
other computers on my home network if I use their names. IP addresses
work OK. I have installed resolvconf and followed several installation
instructions to no avail. The name servers for my router
(192.168.1.1)and both google servers at 8.8.8.8 and 8.8.4.4. are listed
in the correct file (can't remember which one). This system worked fine
when first installed. I installed qemu-kvm on the system and I think in
broke things.I've run out of ideas.

Please help


An addition is necessary here. The problem started when I installed the 
qemu-kvm virtual machine. Now the Kubuntu system - the guest - network 
access works fine. But the host machine can't find the DNS servers. This 
makes no sense.


Gary R

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> as is documented in dhclient-script(8):

Well now that's just EVIL. :-(

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 09:59:26PM +0300, Reco wrote:
> I need to ask - what are you using instead of proper DHCP client?

titan:~$ dpkg -l | grep dhc
ii  isc-dhcp-client   4.3.5-3   
amd64DHCP client for automatically obtaining an IP address
ii  isc-dhcp-common   4.3.5-3   
amd64common manpages relevant to all of the isc-dhcp packages

> Every DHCP client worthy of its name (ISC one, for instance) allows one
> to redefine every part of client configuration via hooks.
> For instance dhcpcd that I use has this specific example in its manpage:
> 
> So to stop dhcpcd from touching your DNS settings or starting
> wpa_supplicant you would do:- nohook resolv.conf, wpa_supplicant

titan:~$ man dhclient | grep resolv
titan:~$ man dhclient.conf | grep resolv
titan:~$ dhclient --help 2>&1 | grep resolv
titan:~$ 

So, your solution was to rip isc-dhcp-client entirely out of the system
and replace it with something else.

Mine was to chattr +i resolv.conf.

The cyberciti.biz FAQ page gives another solution that involves
creating an sh function in some undocumented directory to overwrite
some undocumented internal part of the DHCP client with a function that
does nothing.

What I mean by undocumented: according to the web page, the directory
used to be named /etc/dhcp3/dhclient-enter-hooks.d/ and yet:

titan:~$ man dhclient | grep hook
titan:~$ man dhclient.conf | grep hook
titan:~$ 

I have not tested this solution.  I'm just assuming that it will work
if we replace the old directory name with the new one (/etc/dhcp/...).
I would expect the "hooks.d" part to be in there somewhere.  It's not.

So, if you want to disparage me because I could have done this secret
undocumented ridiculously intrusive thing that one can only learn about
from a third party web page, sure, go ahead.  Tell me how stupid and
lazy I am for preferring a simple command that just WORKS over this
undocumented hook thing, at the same time that you yourself THREW THE
ENTIRE SOFTWARE PACKAGE AWAY rather than try to deal with it.

Fine: I'm stupid and lazy and ignorant and unwilling to learn.

But at least my computer works (now).

Re: Can't find the DNS Servers

[Don Armstrong]

On Mon, 25 Sep 2017, Greg Wooledge wrote:
> Should the dhclient program have a CONFIG FILE OPTION to say
> "NEVER TOUCH THE resolv.conf FILE"?  YES!
> 
> Does it?  NO!

It does. Simply:

cat - < /etc/dhcp/dhclient-enter-hooks.d/disablemakeresolvconf
make_resolv_conf() { : ; }
EOF

as is documented in dhclient-script(8):

   When it starts, the client script first defines a shell function,
   make_resolv_conf , which is later used to create the
   /etc/resolv.conf file. To override the default behaviour,
   redefine this function in the enter hook script.


-- 
Don Armstrong  https://www.donarmstrong.com

An elephant: A mouse built to government specifications.
 -- Robert Heinlein _Time Enough For Love_ p244

Re: Can't find the DNS Servers

[Reco]

Hi.

On Mon, Sep 25, 2017 at 01:53:17PM -0400, Greg Wooledge wrote:

> Would I be happier if I could use a more elegant solution?  Yes.

Being disappointed with built-in Zyxel DHCP server I merely disabled it
and set up a proper ISC DHCP server. I don't know, it's probably
unelegant to you, but it's not a DHCP server unless ISC made it.


> Should the dhclient program have a CONFIG FILE OPTION to say
> "NEVER TOUCH THE resolv.conf FILE"?  YES!
> 
> Does it?  NO!

I need to ask - what are you using instead of proper DHCP client?
Every DHCP client worthy of its name (ISC one, for instance) allows one
to redefine every part of client configuration via hooks.
For instance dhcpcd that I use has this specific example in its manpage:

So to stop dhcpcd from touching your DNS settings or starting
wpa_supplicant you would do:- nohook resolv.conf, wpa_supplicant


> Do I expect it ever to have one in the future?  BWA-hahahaha!  No.

But the future *is* here already.


> So we use what works, because the other choices don't fucking work.

Tsk, tsk. Language. Also, of course they work.

Reco

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 07:32:05PM +0200, Pascal Hambourg wrote:
> Le 25/09/2017 à 17:33, Gene Heskett a écrit :
> > 
> > For me, its a root session, and a "chattr +i resolv.conf"
> 
> Here we have a saying that roughly translates to :
> "When you have a hammer, any problem looks like a nail."

No.  Seriously, just stop.

Those of us who have done chattr +i on one or more systems have, in
many cases, TRIED OTHER SOLUTIONS first and found them wanting.

Take me for example.

At work, I edited /etc/dhcp/dhclient.conf and removed the options that
tell dhclient to ask for domain-name-servers (et al.).  This works fine
for me at work.  The DHCP servers at work respect my wish not to be
given a domain-name-server, so dhclient never touches resolv.conf and
everyone is happy.

Then I tried the same thing at home.

The results were NOT the same.

The Belkin plastic router at home sends me a domain-name-server even
if I do not ask for one.  And dhclient apparently overwrites resolv.conf
every time it receives a domain-name-server from the DHCP server.

EVEN IF IT DID NOT REQUEST ONE.

So, the solution that I used at work does not work at home.

You know what DOES work, though?

chattr +i works.

Do I prefer this solution?  No.

Would I be happier if I could use a more elegant solution?  Yes.

Should the dhclient program have a CONFIG FILE OPTION to say
"NEVER TOUCH THE resolv.conf FILE"?  YES!

Does it?  NO!

Do I expect it ever to have one in the future?  BWA-hahahaha!  No.

So we use what works, because the other choices don't fucking work.

This is not about lack of creativity.

It is not about being too blind or ignorant or stubborn to use the
other solutions.  ("Everything looks like a nail.")

This is about the other soluttions NOT WORKING.

It is about ISC being too blind or ignorant or stubborn to consider that
many people run the DHCP client software WITHOUT being the ones in
charge of the DHCP server on the same network.

Or, not considering that many people use cheap plastic consumer-grade
routers that don't behave the same way the ISC DHCP server behaves.

Am I getting through yet?

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 25/09/2017 à 17:33, Gene Heskett a écrit :


For me, its a root session, and a "chattr +i resolv.conf"


Here we have a saying that roughly translates to :
"When you have a hammer, any problem looks like a nail."

Re: Can't find the DNS Servers

[Reco]

Hi.

On Mon, Sep 25, 2017 at 12:21:49PM -0400, Greg Wooledge wrote:
> On Mon, Sep 25, 2017 at 07:10:10PM +0300, Reco wrote:
> > A common misconception. Here's how a determined userspace can beat
> > immutable bit:
> > 
> > # mkdir testetc
> > # touch testetc/resolv.conf
> > # chattr +i testetc/resolv.conf
> > # mv testetc/ testetc.orig
> > # mkdir testetc
> > # touch testetc/resolv.conf
> > # echo evil dns > testetc/resolv.conf
> 
> You'd have to replace all the other files in /etc as well, or the
> system wouldn't work very well.  But that's not the point.  The point
> isn't to harden the system against an attacker bent on subverting your
> name lookups.  It's to protect your locally modified configuration file
> from being overwritten by well-meaning but stupid software programs.

If the program misbehaves and it cannot be changed - why bother keeping
such program in your OS? I mean, it's Debian maillist, right? Everything
that's misbehaves can be fed to 'apt-get purge' and replaced with
something more sensible.


> (And yes, there are other ways to achieve that, but I've already posted
> the  URL
> in this thread.  Oops, I did it again.)

An interesting link. It lacks my second favorite approach though (first
one being read-only root filesystem):

iptables -t nat -A OUTPUT -p udp ! -d  --port 53 -j DNAT \
--to-destination :53

iptables -t nat -A OUTPUT -p tcp ! -d  --port 53 -j DNAT \
--to-destination :53

ip6tables -A OUTPUT -p udp --dport 53 -j REJECT
ip6tables -A OUTPUT -p tcp --dport 53 -j REJECT

Let them overwrite my resolv.conf with all kinds of gibberish, but it
will resolve the way *I* want it.

Reco

Re: Can't find the DNS Servers

[Nemeth Gyorgy]

2017-09-24 18:14 keltezéssel, Reco írta:
>
> Please post these things from the problematic PC:
>
> ip a l
>
> ip ro l
>
> cat /etc/resolv.conf
and cat /etc/nsswitch.conf

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 07:10:10PM +0300, Reco wrote:
> A common misconception. Here's how a determined userspace can beat
> immutable bit:
> 
> # mkdir testetc
> # touch testetc/resolv.conf
> # chattr +i testetc/resolv.conf
> # mv testetc/ testetc.orig
> # mkdir testetc
> # touch testetc/resolv.conf
> # echo evil dns > testetc/resolv.conf

You'd have to replace all the other files in /etc as well, or the
system wouldn't work very well.  But that's not the point.  The point
isn't to harden the system against an attacker bent on subverting your
name lookups.  It's to protect your locally modified configuration file
from being overwritten by well-meaning but stupid software programs.

(And yes, there are other ways to achieve that, but I've already posted
the  URL
in this thread.  Oops, I did it again.)

Re: Can't find the DNS Servers

[Reco]

Hi.

On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote:
> > I mean, unless this is a laptop or a tablet or a phone or something.
> > Then it may be appropriate, because you might actually WANT your
> > resolv.conf file to be rewritten every time the wind changes
> > direction.
> >
> > For desktop machines with a static internal network configuration,
> > it's an abomination.  And unfortunately it's not the only malevolent
> > fiend trying to usurp control of your resolv.conf file.  There's also
> > dhclient, and network-manager, and systemd-resolved, and who knows
> > what else.
> >
> > See  for
> > some of your options.  Of course, before you can apply any of those
> > suggestions, you have to seize back control of your resolv.conf file
> > in the first place.  Make sure it's a FILE and not a symlink, and put
> > the correct content into it.  Make sure name resolution works.  Then
> > choose your favorite solution to keep the file under YOUR control.
> 
> For me, its a root session, and a "chattr +i resolv.conf"
> If for some reason you need to edit it later, you'll have to use the -i 
> argument first. As long as that +i bit is set, its protected from 
> everything but a mke2fs.

A common misconception. Here's how a determined userspace can beat
immutable bit:

# mkdir testetc
# touch testetc/resolv.conf
# chattr +i testetc/resolv.conf
# mv testetc/ testetc.orig
# mkdir testetc
# touch testetc/resolv.conf
# echo evil dns > testetc/resolv.conf

Of course you could try to counter that with "chattr +i /etc", but doing
*that* should break an unimaginable number of things.

If you really need immutable /etc/resolv.conf you should try the
Read-Only Root Debian - [1].

[1] https://wiki.debian.org/ReadonlyRoot

Reco

Re: Can't find the DNS Servers

[Gene Heskett]

On Monday 25 September 2017 08:56:54 Greg Wooledge wrote:

> On Sat, Sep 23, 2017 at 06:03:12PM -0700, Gary Roach wrote:
> > I have been trying for several day to get firefox to work on a newly
> > installed Debian Stretch system. It Seems that Firefox can't find a
> > DNS server. I am having the same problem with apt-get update. None
> > of my mirrors can be reached.
>
> ls -ld /etc/resolv.conf
> cat /etc/resolv.conf
> dpkg -l resolvconf network-manager
> grep ^hosts: /etc/nsswitch.conf
>
> > Ping works just fine.
>
> pinging what?
>
> > I can't even reach the other computers
> > on my home network if I use their names. IP addresses work OK.
>
> LAN configuration can be done in several ways.  For most small home
> LANs, you probably just want to put the IPs and hostnames in
> /etc/hosts on each machine.
>
> For larger or fancier setups, you can configure a private DNS server.
>
> > I have
> > installed resolvconf
>
> *shudder*

Uncontrollably.

> I mean, unless this is a laptop or a tablet or a phone or something.
> Then it may be appropriate, because you might actually WANT your
> resolv.conf file to be rewritten every time the wind changes
> direction.
>
> For desktop machines with a static internal network configuration,
> it's an abomination.  And unfortunately it's not the only malevolent
> fiend trying to usurp control of your resolv.conf file.  There's also
> dhclient, and network-manager, and systemd-resolved, and who knows
> what else.
>
> See  for
> some of your options.  Of course, before you can apply any of those
> suggestions, you have to seize back control of your resolv.conf file
> in the first place.  Make sure it's a FILE and not a symlink, and put
> the correct content into it.  Make sure name resolution works.  Then
> choose your favorite solution to keep the file under YOUR control.

For me, its a root session, and a "chattr +i resolv.conf"
If for some reason you need to edit it later, you'll have to use the -i 
argument first. As long as that +i bit is set, its protected from 
everything but a mke2fs.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 25/09/2017 à 15:54, Greg Wooledge a écrit :

On Mon, Sep 25, 2017 at 03:45:06PM +0200, Pascal Hambourg wrote:

Prepare to be disappointed if you modify directly resolv.conf, because the
software which wrote it first could rewrite it after you, as DHCP clients do
each time they renew the lease.


In a battle between me and stupid new software programs, I always win
in the end.


I hope so. The user shall prevail.


I will do whatever it takes to make the software behave correctly,
even if what it takes is REMOVING the software.


For sure. But there is the forcible way and the graceful way.

Here is a little experience of mine.
I had a host configured with DHCP. As expected, dhclient wrote the IPv4 
DNS addresses received from the DHCP server into resolv.conf. My network 
also had an IPv6 router sending advertisements containing IPv6 DNS 
addresses and I wanted that addresses to be included in resolv.conf, so 
I installed rdnssd. Unfortunatly, both dhclient and rdnssd rewrote 
resolv.conf, erasing the addresses added by the other. Either DNS 
addresses worked, but it was not what I wanted. Then I installed 
resolvconf and resolv.conf now contained both IPv4 addresses from 
dhclient and IPv6 addresses from rdnssd.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 03:45:06PM +0200, Pascal Hambourg wrote:
> Prepare to be disappointed if you modify directly resolv.conf, because the
> software which wrote it first could rewrite it after you, as DHCP clients do
> each time they renew the lease.

In a battle between me and stupid new software programs, I always win
in the end.

I will do whatever it takes to make the software behave correctly,
even if what it takes is REMOVING the software.

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 25/09/2017 à 15:24, Greg Wooledge a écrit :


I think it's better for all the unix-like systems to work the same way
(the way that they have all done for the last 30+ years), rather than
each one doing something different.

Sadly, there was never any uniformity in how interfaces, IPs, netmasks
and routes are configured.


These two statements contradict each other.
If there was never any uniformity, then Unix-like systems have not 
worked the same way for the 30+ years.



But /etc/resolv.conf is a universal standard.  You can log into ANY
unix-like system and see what nameservers it's using


Yes. But I do not think that the Unix standard defines the way the file 
should be created and modified.



and correct them if they're wrong


Prepare to be disappointed if you modify directly resolv.conf, because 
the software which wrote it first could rewrite it after you, as DHCP 
clients do each time they renew the lease.



(though you may need to remove the chattr +i bit before
you can write to the file).


Ugly hack.

Some software modify the DNS server list. IMO, better bear with it and 
learn how to control them.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 03:14:02PM +0200, Pascal Hambourg wrote:
> Besides, resolvconf is required for the dns-nameservers option in
> /etc/network/interfaces to have any effect with static configuration. Don't
> you think it is better to have all the IP parameters (IP address, mask,
> gateway, DNS) in a single config file ?

No.

I think it's better for all the unix-like systems to work the same way
(the way that they have all done for the last 30+ years), rather than
each one doing something different.

Sadly, there was never any uniformity in how interfaces, IPs, netmasks
and routes are configured.  So, we just have to live with every system
being different for that stuff.

But /etc/resolv.conf is a universal standard.  You can log into ANY
unix-like system and see what nameservers it's using, and correct them
if they're wrong (though you may need to remove the chattr +i bit before
you can write to the file).

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 25/09/2017 à 14:56, Greg Wooledge a écrit :

On Sat, Sep 23, 2017 at 06:03:12PM -0700, Gary Roach wrote:


I have installed resolvconf


*shudder*

I mean, unless this is a laptop or a tablet or a phone or something.
Then it may be appropriate, because you might actually WANT your
resolv.conf file to be rewritten every time the wind changes direction.


resolvconf does not do this.
Besides, resolvconf is required for the dns-nameservers option in 
/etc/network/interfaces to have any effect with static configuration. 
Don't you think it is better to have all the IP parameters (IP address, 
mask, gateway, DNS) in a single config file ?



For desktop machines with a static internal network configuration, it's
an abomination.  And unfortunately it's not the only malevolent fiend
trying to usurp control of your resolv.conf file.  There's also dhclient,
and network-manager, and systemd-resolved, and who knows what else.


resolvconf is designed to prevent these pieces of software to write 
directly in resolv.conf, giving you better control. Without resolvconf, 
all of them wildy rewrite resolv.conf without taking the others into 
account.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Sat, Sep 23, 2017 at 06:03:12PM -0700, Gary Roach wrote:
> I have been trying for several day to get firefox to work on a newly
> installed Debian Stretch system. It Seems that Firefox can't find a DNS
> server. I am having the same problem with apt-get update. None of my mirrors
> can be reached.

ls -ld /etc/resolv.conf
cat /etc/resolv.conf
dpkg -l resolvconf network-manager
grep ^hosts: /etc/nsswitch.conf

> Ping works just fine.

pinging what?

> I can't even reach the other computers
> on my home network if I use their names. IP addresses work OK.

LAN configuration can be done in several ways.  For most small home LANs,
you probably just want to put the IPs and hostnames in /etc/hosts on
each machine.

For larger or fancier setups, you can configure a private DNS server.

> I have
> installed resolvconf 

*shudder*

I mean, unless this is a laptop or a tablet or a phone or something.
Then it may be appropriate, because you might actually WANT your
resolv.conf file to be rewritten every time the wind changes direction.

For desktop machines with a static internal network configuration, it's
an abomination.  And unfortunately it's not the only malevolent fiend
trying to usurp control of your resolv.conf file.  There's also dhclient,
and network-manager, and systemd-resolved, and who knows what else.

See  for
some of your options.  Of course, before you can apply any of those
suggestions, you have to seize back control of your resolv.conf file
in the first place.  Make sure it's a FILE and not a symlink, and put
the correct content into it.  Make sure name resolution works.  Then
choose your favorite solution to keep the file under YOUR control.

Re: Can't find the DNS Servers

[Reco]

Hi.

On Sun, Sep 24, 2017 at 08:55:51AM -0700, Gary Roach wrote:
> Don't know why but this message didn't show up on my email so am sending
> again. Thanks for the reply Cindy Sue.
> 
> Hi all.
> I have been trying for several day to get firefox to work on a newly
> installed Debian Stretch system. It Seems that Firefox can't find a DNS
> server. I am having the same problem with apt-get update. None of my mirrors
> can be reached. Ping works just fine. I can't even reach the other computers
> on my home network if I use their names. IP addresses work OK. I have
> installed resolvconf and followed several installation instructions to no
> avail. The name servers for my router (192.168.1.1)and both google servers
> at 8.8.8.8 and 8.8.4.4. are listed in the correct file (can't remember which
> one). This system worked fine when first installed. I installed qemu-kvm on
> the system and I think in broke things.I've run out of ideas.

Please post these things from the problematic PC:

ip a l

ip ro l

cat /etc/resolv.conf

"tcpdump -nvi any udp port 53 or tcp port 53" run while doing
"getent hosts www.google.com"

Reco

Re: Can't find the DNS Servers

[Cindy-Sue Causey]

On 9/23/17, Gary Roach  wrote:
> Hi all.
> I have been trying for several day to get firefox to work on a newly
> installed Debian Stretch system. It Seems that Firefox can't find a DNS
> server. I am having the same problem with apt-get update. None of my
> mirrors can be reached. Ping works just fine. I can't even reach the
> other computers on my home network if I use their names. IP addresses
> work OK. I have installed resolvconf and followed several installation
> instructions to no avail. The name servers for my router
> (192.168.1.1)and both google servers at 8.8.8.8 and 8.8.4.4. are listed
> in the correct file (can't remember which one). This system worked fine
> when first installed. I installed qemu-kvm on the system and I think in
> broke things.I've run out of ideas.
>
> Please help


Hi, Gary, I absolutely feel your pain. I've been locked out most of
the entire past week. Could mostly only access ~400 to 900 BITES per
second download once in a little while.

After some nosing around, I've initially stumbled upon a quick fix
that will help you at least upgrade right now. This came about k/t an
Ubuntu issue [0].

Yes, I know you're saying you can't access something like that right
now so this is posted in hopes someone can further translate that into
appropriate IP addresses (unless you're accessing from another
computer and can do that yourself, that is).

In the process of learning from that issue over there, this came up:

https://wiki.debian.org/SourcesList#Name_Resolution

VERY cool. It says you can temporarily change your
/etc/apt/sources.list by personalizing the following
*example*/*template*:

echo "deb http://128.30.2.26/debian testing main contrib" >
/etc/apt/sources.list

You simply tweak that to match one's own favored release (e.g. jessie,
stretch, buster, etc) such as it already exists within
/etc/apt/sources.list.

That is SO cool because the tip I learned from Ubuntu was about
tweaking your /etc/hosts. I like tweaking sources.list much better. I
think I like it mostly because it's something more familiar than other
files.

Afterthought is that, because you're only swapping out a domain name
for an IP address (and not touching ANYTHING ELSE), hopefully that
should just keep right on moving from where you left off last time. If
it was me doing this, I would make sure I had a safe backup copy of
sources.list to put back in place when things were solved. :)

So now we hopefully have you upgrading..

Oh, and yes, I know.. there are all kinds of the fancy commands the
rest of everyone uses to debug this type of topic. That right there
above is *so* easy to test drive and is surely a new toy for someone
besides me (too). I even tested http://128.30.2.26/debian/ = IT WORKS
as expected!!!

If it then still doesn't work after upgrading, you can do the tip from
the Ubuntu page where you pick and add appropriate /etc/hosts lines as
you need them. But you need the IP addresses. I've almost figured that
out but not quite.

As it turns out, we might have the power to get those right from our
terminals. I'm not sure if it would work for you, Gary, due to your
issues, but it's a quick install to test and see.

Via Google, I learned about "nslookup". "apt-cache search nslookup"
landed the "dnsutils" package (285kb for me).

Once installed, you type in "nslookup" (as a normal user) and hit
Enter. Then you type in the domain name that needs an IP equivalent.
You'll receive back something like this:

> deb.debian.org
Server: 192.168.0.1
Address:192.168.0.1#53

Non-authoritative answer:
deb.debian.org  canonical name = static.debian.org.
Name:   static.debian.org
Address: 130.89.148.14
Name:   static.debian.org
Address: 149.20.4.15
Name:   static.debian.org
Address: 5.153.231.4
Name:   static.debian.org
Address: 128.31.0.62

That didn't match what Debian Wiki provided so I next tested "dig"
which is also included in dnsutils. I'm not sure how to implement that
one so I'm going to send this off now. Maybe someone else is versed in
"dig" and can help decode its flags, etc. It looks far more powerful
than nslookup.. :)

Or maybe they know an even more productive tool with possibly easier
to remember flags. :)

Originally it had come to mind that there's always the option of
sharing files like these to check for formation and typos:

/etc/network/interfaces
/etc/hosts (before potential tweaking)
/etc/resolv.conf

Those interfaces and hosts files are places I have to touch on and
sometimes fill in some things for during each new debootstrap. That
tells me they're places where things can get messed up.

That /etc/resolv.conf always resolves itself for me, yayhoo, but maybe
something's not quite ok in yours. I'm saying that because my notes
are showing one thing, and now my own /etc/resolv.conf has apparently
populated itself with an additional line these days.

Beyond that, I'm pretty much... speechless. :)

Cindy :)

[0]