Quoting Jochen Spieker (m...@well-adjusted.de):
> David Wright:
> > Quoting Jochen Spieker (m...@well-adjusted.de):
> >> 
> >> Where's the problem in Apache using your router's DNS? Is it just that
> >> the router doesn't resolve unqualified names (supercrunch without the
> >> domain)?
> > 
> > I didn't know bog-standard domestic routers ran a DNS server.
> 
> I think all of them do. They have simple caching-only DNS servers that
> just ask your ISP's DNS resolver for all but local hostnames.
> 
> Your computers should request an IP address and at the same time
> register what they think is their local hostname on the router (all via
> DHCP).

Yes, all that happens. I have the same hostname written in three
places:
1) the router, which has a list of IP#s/device names/MAC addresses
   in order that it always issues the same IP# for a given device
   via (DHCP),
2) /etc/hosts: 127.0.1.1 here or 192.168.1.N elsewhere,
3) wicd configuration.

> This way your router's DNS server should be able to resolve local
> hostnames for other clients, rendering your editing of hosts files
> unnecessary.

Yes, but a bog-standard one doesn't appear to have even a simple
caching-only DNS server, only a DHCP one.

> Usually your router also tells the DHCP clients the name of the network
> they are in. My AVM Fritzbox (German manufacturer) hands out
> ".fritz.box" which I find so horrible that I run a separate DNS/DHCP
> server (dnsmasq) on another box.

At some time IIRC Debian put   localnet 192.168.1.0   into
/etc/networks but I'm not sure if that's still true. Hosts that have
that line may be cruft-laden as a result of being upgraded over several
distributions (squeeze is now my earliest dist origin.)

> > I thought they just asked the external nameservers, either set up
> > automatically from the ISP or manually configured if using public ones.
> 
> That plus resolution of local hostnames.

... if they themselves run a nameserver.

> >> Using an IP address as ServerName is odd. You have to use the hostname
> >> that you want to use in URLs here.
> >
> > The latter seems odd, seeing as the first thing you would normally do
> > with a hostname is look it up and turn it into an IP address.
> 
> Yes, but most people are better at remembering names than IP addresses
> and the lookup is performed automatically whenever you use it.

(Tell me about it! That's why I've always argued that the Grub scripts
ought to treat LABELs on a par with UUIDs as they're much easier for
humans to handle.)

> How often do you open http://173.194.116.166 in order to go to Google?
> Or, god forbid, http://[2a00:1450:4001:80e::1009] (in case you already
> have IPv6)?

Never, for google etc. That was not my point, which was that the first
thing *computers* do is look up the IP#. I think you'd be surprised if
your browser *couldn't* handle, say, http://173.194.115.80/ but *could*
handle http://www.google.com/.

(However, my computers all have
Acquire::http::Proxy "http://192.168.1.19:3142/";;
in /etc/apt/apt.conf because at installation time they have no
way of looking up that computer's hostname.)

So why would 127.0.0.1 be any odder than localhost? My browsers are
quite happy with any of
http://localhost:3142/acng-report.html
http://127.0.0.1:3142/acng-report.html
http://192.168.1.19:3142/acng-report.html
http://alum:3142/acng-report.html
http://127.0.1.1:3142/acng-report.html

> > I don't know how you have your LAN configured. I use DHCP from the
> > router, which assigns fixed IP#s by MAC address. That way, I can
> > list my own hosts in /etc/hosts and avoid needing a DNS server to
> > resolve their names:
> > 
> > 127.0.0.1       localhost
> > 127.0.1.1       thishost
> > 192.168.1.1     router
> > 192.168.1.11    otherhosta
> > 192.168.1.12    otherhostb
> > 192.168.1.31    HP0C00E0    hp8000
> 
> … and you have to keep that file in sync on all hosts. I use DHCP as
> well and make sure my clients send their hostname when requesting an IP
> address vie DHCP. Debian does this automatically. Then all clients in
> the local network can resolve their names just fine and I don't need to
> edit hosts files.

Obviously you have something which many people don't have. So
I can't do it that way.

> I do use fixed IPs for a few hosts as well, but mostly because I use
> port forwardings or local services that I want to bind to a specific
> address. But this is just a configuration on the DHCP server and nothing
> I have to repeat on all boxes in my network.

All my hosts (and the TVs/Roku boxes/printers.mobiles) have fixed IP#s
set by the router as at (1) above.

> If this sounds as if I had an awful lot of computers: no, I don't think
> so. It's just an awful lot of, well, _devices_ with wired/wireless
> networking capability:

Yes, likewise. 14 MAC addresses in the router, a slightly different mix.

[...]

> Yes, I may be guilty of overengineering a few things. But I now spend
> considerably less time with this than a few years ago and I think this
> is related to the way I have set things up.

I use scripts to configure my Debian systems so it's quick.

> > I don't set any domainname. The only consequence I know of is exim
> > complaining at boot:
> > 
> > Starting MTA:hostname --fqdn did not return a fully qualified name, 
> > dc_minimaldns will not work.
> > Please fix your /etc/hosts setup.
> 
> Well, Exim is written primarily as a "real" mail server (MTA). Your
> usage is supported (and common), but the authors just expect a "proper"
> environment. A network without a name (not even a fake name) isn't.

Exim was written by a guy who hacked code to suit the environment in
which it found itself. Single-user machines are just one mode of use,
and one that the author had to come to grips with (in terms of support
and documentation) when it became popular on linux, particularly Debian.

> Anyway, sorry that I am not really helping you with your redmine issue.

I'm not the one with the issue. I'm more interested in software that
apparently relies on the resolving of dotless hostnames by DNS (rather
than files) and objects to the IP# in place of the hostname.

Cheers,
David.

Reply via email to