Is there any point to full host names in /etc/hosts ?

On Sat, 03 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <m3bqabqmh6.fsf@chatteau.d.lf>, Ashish Shukla
=?utf-8?B?4KSG4KS24KWA4KS3IOCktg==?= =?utf-8?B?4KWB4KSV4KWN4KSy?= wrote:
[color=blue]
> Stefan Monnier writes:[/color]
[color=blue]
>| Better yet: the name they get is determined by the machine's name
>| (passed to the DHCP server), so I don't even have a centralized database
>| that maps names to IP either: it's all setup dynamically (although you
>| do have to ask GNU/Linux's dhcp client to pass this name explicitly
>| because it doesn't do it by default contrary to Mac OS X's).[/color]

Of course, even the id10ts at Apple and Microsoft admit this is a rather
massive security hole.
[color=blue]
>Why not use Avahi[1] ( which provides mDNS[2] ) and libnss-mdns[3] (nss
>plugin for name resolving using mDNS) .
>
>[1]. [url]http://www.avahi.org/[/url]
>[2]. [url]http://en.wikipedia.org/wiki/Zeroconf[/url]
>[3]. [url]http://0pointer.de/lennart/projects/nss-mdns/[/url][/color]

Avahi uses port 5353 to 224.0.0.251 or its IPv6 equivalent FF02::FB,
while the microsoft version uses 5355 to 224.0.0.252 or its IPv6
equivalent FF02::1:3. See

4795 Link-local Multicast Name Resolution (LLMNR). B. Aboba, D.
Thaler, L. Esibov. January 2007. (Format: TXT=71969 bytes)
(Status: INFORMATIONAL)

verses

draft-cheshire-dnsext-multicastdns-06.txt (which seems to have
quietly been allowed to expire without replacement, though copies are
still available on the Internet) which was the Apple working paper
version of the draft to provide mDNS.

The RFC for "Link-Local" (also known as ZeroConf) is RFC3927:

3927 Dynamic Configuration of IPv4 Link-Local Addresses. S. Cheshire,
B. Aboba, E. Guttman. May 2005. (Format: TXT=83102 bytes) (Status:
PROPOSED STANDARD)

and specified the unpublished draft for what became RFC4795, and
specifically requires that any queries for an address-to-hostname
query in the '254.169.in-addr.arpa.' domain be result in an RCODE=3
(NXDOMAIN) response.

Without the optional DNSSEC, both proposals (the microsoft version
went through at least draft-ietf-dnsext-mdns-47.txt - the 47th
revision - before being adopted as RFC4795) should be restricted to
networks where it is unlikely to find bad guys. The microsoft
version suggests that it be limited to hostnames _without_ a 'dot'
(".") which they call 'single-label' names, but actually make no tests
to see (and ignores) if any are included in the query. The Apple
version was slightly safer, being restricted to names ending in
".local", but warned against having 'search' or 'domain' lines in
/etc/resolv.conf, and also mentioned that some name resolvers fail
to include a trailing dot in the FQDN hostname queries (Linux does
include the dot - making the query 'absolute' rather than relative).

Old guy

On Sat, 3 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in article
<scpuv4-6f6.ln1@whisper.very.softly>, Rikishi 42 wrote:
[color=blue]
>Moe Trin <ibuprofin@painkiller.example.tld> wrote:[/color]
[color=blue][color=green]
>> Rikishi 42 wrote:[/color][/color]
[color=blue][color=green][color=darkred]
>>># Home net
>>>192.168.108.101 desktop.myDomain desktop
>>>192.168.108.124 laptop.myDomain laptop
>>>192.168.108.101 server.myDomain server[/color]
>>
>> Minor quibble - a given hostname OR IP address should appear on one
>> line only.[/color]
>
>That would be my fault, I messed up the example. In the real file,
>there are no double entries.[/color]

It's not as if it's going to horribly break things - the worst it
will do is return the wrong hostname or slow things down. If your
system still has a hosts(5) man page, it's mentioned there.

So have you found the actual problem yet? As this thread has shown,
there are several possible causes.

Old guy

On 2007-11-04, David Brown <david.brown@hesbynett.removethisbit.no> wrote:[color=blue]
> Moe Trin wrote:[color=green]
>> On Fri, 2 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in article
>> <b5frv4-0qn.ln1@whisper.very.softly>, Rikishi 42 wrote:
>>[color=darkred]
>>> He's added 2 of my PC's in the /etc/hosts of his laptop, for use when he
>>> visits and connects it to my LAN.
>>>
>>> This would be a sample from that file:
>>>
>>> # Home net
>>> 192.168.108.101 desktop.myDomain desktop
>>> 192.168.108.124 laptop.myDomain laptop
>>> 192.168.108.101 server.myDomain server[/color]
>>
>> Minor quibble - a given hostname OR IP address should appear on one
>> line only.
>>[/color]
>
> If you are using the hosts file to avoid web advertisements or other
> sites you want to avoid, the hosts file generally contains a long list
> of "127.0.0.1 ads.doubleclick.net" lines, with every line resolving to
> the same IP address. Is there some problem with lists like that?[/color]
No, that has nothing to do with the purpose.

Thanks.

--
There is an art, it says, or rather, a knack to flying.
The knack lies in learning how to throw yourself at the ground and miss.
Douglas Adams

On Sun, 04 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <472de7fd$0$3510$8404b019@news.wineasy.se>, David Brown wrote:
[color=blue]
>Moe Trin wrote:[/color]
[color=blue][color=green]
>> Minor quibble - a given hostname OR IP address should appear on one
>> line only.[/color][/color]
[color=blue]
>If you are using the hosts file to avoid web advertisements or other
>sites you want to avoid, the hosts file generally contains a long list
>of "127.0.0.1 ads.doubleclick.net" lines, with every line resolving to
>the same IP address. Is there some problem with lists like that?[/color]

Generally that technique slows things down. In theory, you can list
multiple host _names_ on each line (and the lines can be long), but
_any_ IP address in the range 127.0.0.0 through 127.255.255.254 resolves
to 'localhost'.

[compton ~]$ ping -qc 1 127.0.0.0
PING 127.0.0.0 (127.0.0.0): 56 data bytes

--- 127.0.0.0 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.3 ms
[compton ~]$ ping -qc 1 127.2.3.4
PING 127.2.3.4 (127.2.3.4): 56 data bytes

--- 127.2.3.4 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.3 ms
[compton ~]$ ping -qc 1 127.255.255.254
PING 127.255.255.254 (127.255.255.254): 56 data bytes

--- 127.255.255.254 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.3/0.3 ms
[compton ~]$

so you could put 4,294,967,295 lines in there. Might take a bit of
extra RAM on your part, and would slow your browsing to a crawl, but
it's possible. (Running your own DNS would probably be quicker.)

Old guy

On 2007-11-04, Moe Trin <ibuprofin@painkiller.example.tld> wrote:[color=blue][color=green][color=darkred]
>>> Minor quibble - a given hostname OR IP address should appear on one
>>> line only.[/color]
>>
>>That would be my fault, I messed up the example. In the real file,
>>there are no double entries.[/color]
>
> It's not as if it's going to horribly break things - the worst it
> will do is return the wrong hostname or slow things down. If your
> system still has a hosts(5) man page, it's mentioned there.
>
> So have you found the actual problem yet? As this thread has shown,
> there are several possible causes.[/color]

Nah, he only visits every 2-3 weeks. Maybe he'll be here next friday.
We'll see.
[color=blue]
> Old guy[/color]
Even older guy. (at least, I feels like it)


--
There is an art, it says, or rather, a knack to flying.
The knack lies in learning how to throw yourself at the ground and miss.
Douglas Adams

>> | Better yet: the name they get is determined by the machine's name[color=blue][color=green]
>> | (passed to the DHCP server), so I don't even have a centralized database
>> | that maps names to IP either: it's all setup dynamically (although you
>> | do have to ask GNU/Linux's dhcp client to pass this name explicitly
>> | because it doesn't do it by default contrary to Mac OS X's).[/color][/color]
[color=blue]
> Of course, even the id10ts at Apple and Microsoft admit this is a rather
> massive security hole.[/color]

Do you have any pointers to info about that "massive security hole"?


Stefan

Floyd L. Davidson wrote:[color=blue]
> Rikishi 42 <skunkworks@rikishi42.net> wrote:[color=green]
>> On 2007-11-03, Send <Send@Nospam.com> wrote:[color=darkred]
>>> Rikishi 42 wrote:
>>>> This is the situation: a friend and I both use a broadband router with a few
>>>> machines behind them, at our respective homes. We each picked a name for our
>>>> 'domain'. His is fictional. Mine also exists on the net, but with only the
>>>> www and ftp of rikishi42.net defined in the DNS, not my home machines.
>>>>
>>> stealing - Using some one elses domain name is unethical. Bottom line
>>> "IT'S NOT YOURS"[/color]
>> Yes it is. Read the headers...[/color]
>
> Even if it wasn't, the idea that using it as you are is
> "unethical" is merely hilarious. Ignore this guy.
>[color=green]
>> You *are* stoned out of your mind, aren't you. :-)[/color]
>
> Good observation, me thinks...
>[/color]

Guess you can't read your TOS ...

Rikishi 42 wrote:[color=blue]
> On 2007-11-03, Send <Send@Nospam.com> wrote:[color=green]
>> Rikishi 42 wrote:[color=darkred]
>>> This is the situation: a friend and I both use a broadband router with a few
>>> machines behind them, at our respective homes. We each picked a name for our
>>> 'domain'. His is fictional. Mine also exists on the net, but with only the
>>> www and ftp of rikishi42.net defined in the DNS, not my home machines.
>>>[/color]
>> stealing - Using some one elses domain name is unethical. Bottom line
>> "IT'S NOT YOURS"[/color]
> Yes it is. Read the headers...[/color]

Are You trolling Read Youyr own post You said & I Quote
"Mine also exists on the net"
[color=blue]
>
>[color=green]
>> 192.168.xxx.xxx addresses are private network addresses and usually not
>> forwarded upstream by a router. Can you imagine what would happen if
>> everyone using the same addresses allowed all their network traffic to
>> reach the www. They would be mass collisions Not to mention that your
>> private network is no longer "private".
>>
>> Be forewarned of the security implications[/color]
> Are you on medication? Or did you just miss the original post?[/color]

What You have trouble reading ... The original is Quoted DUA
[color=blue]
>
>[color=green][color=darkred]
>>> My guess is that, upon finding that rikishi42.net exists, there is an
>>> attempt to get the address from the DNS, skipping hosts all together.
>>>
>>> But do I presume correctly, or is there more to it?
>>>[/color]
>> Why bother with all this ? Do it right. Just use the name & IP address
>> that has been assigned to you by your ISP. If you are assigned a
>> dynamic (IP address changes from time to time) which they normally are
>> then use a FREE service like DynDns and have your own "REAL" domain ...
>>
>> "YOU".dyndns.org
>>
>> they have several domain you can pick from other than dyndns.org. There
>> are programs you can run that will update the Dyndns listing
>> automatically when your ISP changes your IP address.
>>
>> Dns lookup Work ... Other friends anyware can reach your machine and you
>> will NOT be blocked by upstream routers.[/color]
> You *are* stoned out of your mind, aren't you. :-)
>
>
> Please, please read the original post, and grep it.[/color]


You asked for the help .. Go play with your dolls somewhere OFF Usenet
INTERNET


[color=blue]
>[/color]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

,--- Moe Trin writes:

[...]

| The RFC for "Link-Local" (also known as ZeroConf) is RFC3927:

| 3927 Dynamic Configuration of IPv4 Link-Local Addresses. S. Cheshire,
| B. Aboba, E. Guttman. May 2005. (Format: TXT=83102 bytes) (Status:
| PROPOSED STANDARD)

| and specified the unpublished draft for what became RFC4795, and
| specifically requires that any queries for an address-to-hostname
| query in the '254.169.in-addr.arpa.' domain be result in an RCODE=3
| (NXDOMAIN) response.

Correct, because those (169.254/16 and fe80::/10) are link-local addresses.

| Without the optional DNSSEC, both proposals (the microsoft version
| went through at least draft-ietf-dnsext-mdns-47.txt - the 47th
| revision - before being adopted as RFC4795) should be restricted to
| networks where it is unlikely to find bad guys.

That's the demerit of this approach, if it's decentralized, it has to
be explicitely proved authentic :( .

| The microsoft
| version suggests that it be limited to hostnames _without_ a 'dot'
| (".") which they call 'single-label' names, but actually make no tests
| to see (and ignores) if any are included in the query. The Apple
| version was slightly safer, being restricted to names ending in
| ".local", but warned against having 'search' or 'domain' lines in
| /etc/resolv.conf, and also mentioned that some name resolvers fail
| to include a trailing dot in the FQDN hostname queries (Linux does
| include the dot - making the query 'absolute' rather than relative).

The .local TLD thing is correct approach, because it distinguishes
what is local rather than no domain or simply any domain[1].

| Old guy

[1] [url]http://www.mhonarc.org/archive/html/ietf/2005-08/msg00494.html[/url]

HTH
- --
Ashish Shukla आशीष शुक्ल [url]http://wahjava.wordpress.com/[/url]
·-- ·- ···· ·--- ·- ···- ·- ·--·-· --· -- ·- ·· ·-·· ·-·-·- -·-· --- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHLuj6Hy+EEHYuXnQRAt+vAKCFVq1qQWkUiYqIjQXMNeHiWxZcxwCfb79o
Ewc4x7hnr7V7i5GCGBTLG0A=
=Lr6x
-----END PGP SIGNATURE-----

Moe Trin wrote:[color=blue]
> On Sun, 04 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
> article <472de7fd$0$3510$8404b019@news.wineasy.se>, David Brown wrote:
>[color=green]
>> Moe Trin wrote:[/color]
>[color=green][color=darkred]
>>> Minor quibble - a given hostname OR IP address should appear on one
>>> line only.[/color][/color]
>[color=green]
>> If you are using the hosts file to avoid web advertisements or other
>> sites you want to avoid, the hosts file generally contains a long list
>> of "127.0.0.1 ads.doubleclick.net" lines, with every line resolving to
>> the same IP address. Is there some problem with lists like that?[/color]
>
> Generally that technique slows things down. In theory, you can list
> multiple host _names_ on each line (and the lines can be long), but
> _any_ IP address in the range 127.0.0.0 through 127.255.255.254 resolves
> to 'localhost'.
>
> [compton ~]$ ping -qc 1 127.0.0.0
> PING 127.0.0.0 (127.0.0.0): 56 data bytes
>
> --- 127.0.0.0 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max = 0.3/0.3/0.3 ms
> [compton ~]$ ping -qc 1 127.2.3.4
> PING 127.2.3.4 (127.2.3.4): 56 data bytes
>
> --- 127.2.3.4 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max = 0.3/0.3/0.3 ms
> [compton ~]$ ping -qc 1 127.255.255.254
> PING 127.255.255.254 (127.255.255.254): 56 data bytes
>
> --- 127.255.255.254 ping statistics ---
> 1 packets transmitted, 1 packets received, 0% packet loss
> round-trip min/avg/max = 0.3/0.3/0.3 ms
> [compton ~]$
>
> so you could put 4,294,967,295 lines in there. Might take a bit of
> extra RAM on your part, and would slow your browsing to a crawl, but
> it's possible. (Running your own DNS would probably be quicker.)
>
> Old guy[/color]

I have a dnsmasq DNS server for the network, so I'd put the hosts list
there for the benefit of all machines. It would not actually be in the
system's /etc/hosts file, but a separate file in the same format, loaded
by dnsmasq. Readily available host lists on the Internet that I looked
at all have a single 127.0.0.1 address, but it would be easy enough to
change the lines as you suggest with a little script - but would that
make any difference in practice? And would windows clients on the
network follow the rules and work with 127.*.*.* addresses? (brief
testing suggests yes, but I value the experience of others).

mvh.,

David

On 2007-11-05, Send <Send@Nospam.com> wrote:[color=blue]
> Rikishi 42 wrote:[color=green]
>> On 2007-11-03, Send <Send@Nospam.com> wrote:[color=darkred]
>>> Rikishi 42 wrote:
>>>> This is the situation: a friend and I both use a broadband router with a few
>>>> machines behind them, at our respective homes. We each picked a name for our
>>>> 'domain'. His is fictional. Mine also exists on the net, but with only the
>>>> www and ftp of rikishi42.net defined in the DNS, not my home machines.
>>>>
>>> stealing - Using some one elses domain name is unethical. Bottom line
>>> "IT'S NOT YOURS"[/color]
>> Yes it is. Read the headers...[/color]
>
> Are You trolling Read Youyr own post You said & I Quote
> "Mine also exists on the net"[/color]

Exactly. So where is the stealing? It's *mine*.
[color=blue][color=green][color=darkred]
>>> 192.168.xxx.xxx addresses are private network addresses and usually not
>>> forwarded upstream by a router. Can you imagine what would happen if
>>> everyone using the same addresses allowed all their network traffic to
>>> reach the www. They would be mass collisions Not to mention that your
>>> private network is no longer "private".
>>>
>>> Be forewarned of the security implications[/color]
>> Are you on medication? Or did you just miss the original post?[/color]
>
> What You have trouble reading ... The original is Quoted DUA[/color]

We are not putting the 192.168.x.x addresses in any DNS, nor using trough
the Internet.
I use it, between my machines.
He uses it between his machines.
He's added 2 of my machines into his laptop's /etc/hosts, so he can use it
when he's visiting me, and connects to my LAN. From my home, in my home.

Never is that non-routable range used on the Net, for $DEITY's sake.
[color=blue][color=green][color=darkred]
>>>> My guess is that, upon finding that rikishi42.net exists, there is an
>>>> attempt to get the address from the DNS, skipping hosts all together.
>>>>
>>>> But do I presume correctly, or is there more to it?
>>>>
>>> Why bother with all this ? Do it right. Just use the name & IP address
>>> that has been assigned to you by your ISP. If you are assigned a
>>> dynamic (IP address changes from time to time) which they normally are
>>> then use a FREE service like DynDns and have your own "REAL" domain ...[/color][/color][/color]

And just how many IP's do you get from your ISP? I get 2, and that just not
enough. Hence the used of a broadband router.
[color=blue][color=green][color=darkred]
>>> they have several domain you can pick from other than dyndns.org. There
>>> are programs you can run that will update the Dyndns listing
>>> automatically when your ISP changes your IP address.[/color][/color][/color]
Since they aren't used on the Net, there is no point in DynDNS.
[color=blue][color=green][color=darkred]
>>> Dns lookup Work ... Other friends anyware can reach your machine and you
>>> will NOT be blocked by upstream routers.[/color]
>> You *are* stoned out of your mind, aren't you. :-)
>>
>>
>> Please, please read the original post, and grep it.[/color]
>
> You asked for the help[/color]
Yep, and I appreciate all help I've gotten. I'll be examining my friends
nsswitch config, first.

You had misunderstood the question so much, it amased not only me, but
other's as well. If you want to understand, please read the original post,
and _all_ the answers people posted. But I allready suggested that, and you
didn't bother, did you? :-)
[color=blue]
>.. Go play with your dolls somewhere OFF Usenet
> INTERNET[/color]
Usenet INTERNET ? Weird.


--
There is an art, it says, or rather, a knack to flying.
The knack lies in learning how to throw yourself at the ground and miss.
Douglas Adams

On Sun, 04 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <jwvd4up4cxx.fsf-monnier+comp.os.linux.networking@gnu.org>,
Stefan Monnier wrote:
[color=blue][color=green][color=darkred]
>>>| Better yet: the name they get is determined by the machine's name
>>>| (passed to the DHCP server), so I don't even have a centralized
>>>| database that maps names to IP either: it's all setup dynamically
>>>| (although you do have to ask GNU/Linux's dhcp client to pass this
>>>| name explicitly because it doesn't do it by default contrary to
>>>| Mac OS X's).[/color][/color]
>[color=green]
>> Of course, even the id10ts at Apple and Microsoft admit this is a
>> rather massive security hole.[/color]
>
>Do you have any pointers to info about that "massive security hole"?[/color]

You could start with the RFCs themselves, right back to RFC1542 back
in 1993. DHCP has never been secure, as it was never intended to be.
The first RFC to even include the words 'security' or 'secure' in it's
title was RFC1038 in 1988 (finalized by the historic and virtually
unknown RFC1108 from 1991). You may want to look at RFC1244 (which was
replaced by RFC2196 in 1997). As far as DNS goes, start with RFC1535.

1535 Security Problem and Proposed Correction With DNS Software Oct. 1993
2131 Dynamic Host Configuration Protocol. Mar. 1997
2132 DHCP Options and BOOTP Vendor Extensions. Mar. 1997
2136 Dynamic Updates in the Domain Name System (DNS UPDATE). Apr. 1997
2137 Secure Domain Name System Dynamic Update. ->RFC3007

and follow the chain from there. Note that since the 1990s, most RFCs
include a 'Security Considerations' section near the back of the
document, where they lightly mention such issues. The section in the
ZeroConf/Link-Local RFC (RFC3927) is entertaining.

[url]ftp://ftp.isi.edu/in-notes/rfc-index.txt[/url]

-rw-r--r-- 1 ftpuser ftpusers 842402 Nov 4 23:45 rfc-index.txt

and that does not include the 'draft' RFCs in /in-notes/drafts/

-rwxr-xr-x 1 ftpuser ftpusers 233567 Nov 5 01:00 1id-index.txt

Old guy

On Mon, 05 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <m33avlaubq.fsf@chatteau.d.lf>, Ashish Shukla
=?utf-8?B?4KSG4KS24KWA4KS3IOCktg==?= =?utf-8?B?4KWB4KSV4KWN4KSy?= wrote:
[color=blue]
>Moe Trin writes:[/color]
[color=blue]
>| Without the optional DNSSEC, both proposals (the microsoft version
>| went through at least draft-ietf-dnsext-mdns-47.txt - the 47th
>| revision - before being adopted as RFC4795) should be restricted to
>| networks where it is unlikely to find bad guys.
>
>That's the demerit of this approach, if it's decentralized, it has to
>be explicitely proved authentic :( .[/color]

Unfortunately, the 'customers' (generally speaking, the users) don't
want to put up with the hassle of doing so. Most of them can't even
_spell_ the word 'certificate' never mind have any idea what it might
be - 'is there a "padlock?"' is the absolute limit of their concepts.
[color=blue]
>| The microsoft version suggests that it be limited to hostnames
>| _without_ a 'dot' (".") which they call 'single-label' names, but
>|actually make no tests to see (and ignores) if any are included in
>|the query.[/color]

The 'single-label' concept goes back to their NETBIOS networking,
which - being designed for small offices - didn't need a domain style
of hostnames. It was only when microsoft realized that the Internet
community wasn't going to replace IP with NETBIOS that they even
thought of the larger picture. However, for 'user friendly' mode
of operations ("damn the security, just make it work"), they've been
forced to live with their small office concepts.
[color=blue]
>| The Apple version was slightly safer, being restricted to names
>| ending in ".local", but warned against having 'search' or 'domain'
>| lines in /etc/resolv.conf,[/color]
[color=blue]
>The .local TLD thing is correct approach, because it distinguishes
>what is local rather than no domain or simply any domain[1].[/color]

However that assumes that the users are even aware of the concept.
Microsoft knows that the average user has no idea that domain names
might end in something other than '.com' and their EULA dumps all
responsibility on the user for any security gaffes. Also, it was the
microsoft proposal (draft-ietf-dnsext-mdns-*) that got adopted (at
least only as an 'INFORMATIONAL' document), rather than the slightly
less insane draft-cheshire-dnsext-multicastdns-*.

Old guy

>>>> | Better yet: the name they get is determined by the machine's name[color=blue][color=green][color=darkred]
>>>> | (passed to the DHCP server), so I don't even have a centralized
>>>> | database that maps names to IP either: it's all setup dynamically
>>>> | (although you do have to ask GNU/Linux's dhcp client to pass this
>>>> | name explicitly because it doesn't do it by default contrary to
>>>> | Mac OS X's).[/color]
>>[color=darkred]
>>> Of course, even the id10ts at Apple and Microsoft admit this is a
>>> rather massive security hole.[/color]
>>
>> Do you have any pointers to info about that "massive security hole"?[/color][/color]
[color=blue]
> You could start with the RFCs themselves, right back to RFC1542 back
> in 1993. DHCP has never been secure, as it was never intended to be.
> The first RFC to even include the words 'security' or 'secure' in it's
> title was RFC1038 in 1988 (finalized by the historic and virtually
> unknown RFC1108 from 1991). You may want to look at RFC1244 (which was
> replaced by RFC2196 in 1997). As far as DNS goes, start with RFC1535.[/color]

I guess we misunderstood each other. I mean: which part of what I described
introduces a massive security hole and what is this security hole. Are just
referring to the use of DHCP (that's apparently the case) or to the act of
passing (and using) a hostname to the DHCP server?

Obviously there's no hope of security when you plug your machine into some
foreign network and ask for an IP. DHCP can't be blamed for that, really.


Stefan

On Mon, 05 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <472f8765$0$3209$8404b019@news.wineasy.se>, David Brown wrote:
[color=blue]
>I have a dnsmasq DNS server for the network, so I'd put the hosts list
>there for the benefit of all machines. It would not actually be in the
>system's /etc/hosts file, but a separate file in the same format, loaded
>by dnsmasq.[/color]

DNS is not the hosts file, and different rules apply. What is often a
problem in DNS setups is the accidental use of wild-cards - which mean
that all hostsnames _other_than_ those with A records return a 'default'
address. Think of a zonefile where there are A records for hosts
A.example.com, B.example.com, and C.example.com. If asked about host
D.example.com (for which there is no A record), the name server returns
a "valid" answer of (for example) 192.0.2.222 - usually because of a
'*' character in a hostname record in the zone file (such as
'*.example.com IN A 192.0.2.222')

See the documentation for your nameserver, as there may be differences.
[color=blue]
>Readily available host lists on the Internet that I looked at all have
>a single 127.0.0.1 address, but it would be easy enough to change the
>lines as you suggest with a little script - but would that make any
>difference in practice?[/color]

Yeah - I've seen lists like that, which may contain as many as several
thousand addresses and address ranges. Most seem to be designed for
windoze users, and I've no experience with that.
[color=blue]
>And would windows clients on the network follow the rules and work
>with 127.*.*.* addresses? (brief testing suggests yes, but I value the
>experience of others).[/color]

I would expect so, but have no windoze boxes to test it.

Old guy

On Tue, 06 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <jwvzlxrep3d.fsf-monnier+comp.os.linux.networking@gnu.org>,
Stefan Monnier wrote:
[color=blue][color=green][color=darkred]
>>> Do you have any pointers to info about that "massive security hole"?[/color][/color][/color]
[color=blue][color=green]
>> You could start with the RFCs themselves[/color][/color]
[color=blue]
>I guess we misunderstood each other. I mean: which part of what I
>described introduces a massive security hole and what is this security
>hole. Are just referring to the use of DHCP (that's apparently the
>case)[/color]

Mainly
[color=blue]
>or to the act of passing (and using) a hostname to the DHCP server?[/color]

You're adding another chance for spoofing, unless you are able to
verify that the host claiming to be 'foo.example.com' really is. You
are depending that anyone able to provide data to your DHCP server is
not providing malicious data. Claimed names, or even MAC addresses
can not be trusted. If the user on a given host lacks administrative
or root privilege, it's harder to set up spoofing, but many users
have these elevated privileges.

Actually, the spoofing doesn't even have to be malicious. I've seen
instances where the same hostname was chosen by different individuals.
This often worked for a while because the two were not connected at the
same time. A friend who admin's at a local community college tells of
one individual was running a game server of some kind which was popular
with other students. The second person using the same hostname was quite
paranoid, and kept complaining that other systems were "attacking" his
computer... bet you can figure out what the "attacks" were.
[color=blue]
>Obviously there's no hope of security when you plug your machine into
>some foreign network and ask for an IP. DHCP can't be blamed for that,
>really.[/color]

Very true. It was never designed for that function. But don't forget
that this was also the era of the Berkeley 'r' commands, and the
network authentication based on hostnames. Hostnames, IP or MAC
addresses can be faked. Using an unauthenticated dynamic hostname
just makes it a lot easier.

Old guy

Moe Trin wrote:[color=blue]
> On Mon, 05 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
> article <472f8765$0$3209$8404b019@news.wineasy.se>, David Brown wrote:
>[color=green]
>> I have a dnsmasq DNS server for the network, so I'd put the hosts list
>> there for the benefit of all machines. It would not actually be in the
>> system's /etc/hosts file, but a separate file in the same format, loaded
>> by dnsmasq.[/color]
>
> DNS is not the hosts file, and different rules apply. What is often a
> problem in DNS setups is the accidental use of wild-cards - which mean
> that all hostsnames _other_than_ those with A records return a 'default'
> address. Think of a zonefile where there are A records for hosts
> A.example.com, B.example.com, and C.example.com. If asked about host
> D.example.com (for which there is no A record), the name server returns
> a "valid" answer of (for example) 192.0.2.222 - usually because of a
> '*' character in a hostname record in the zone file (such as
> '*.example.com IN A 192.0.2.222')
>
> See the documentation for your nameserver, as there may be differences.
>[/color]

I'll check the documentation for dnsmasq. The reason I was asking
regarding DNS serving is that dnsmasq can pre-load names from any files
in the same format as /etc/hosts (including /etc/hosts itself), and
treat these entries as A records. This would make it particularly easy
to use a ready-made hosts file, and would let clients on the network
take advantage of the redirection without the hassle of updating every
client's hosts file, and without the slowdown associated with big hosts
files on windows.

I've had an idea for improving this too - rather than pointing all these
advertising servers towards 127.0.0.1 (or 127.x.x.x), I could point them
towards an internal web server with re-write rules so that any requests
for a .gif file would return a 1-pixel blank gif, and so on for other
file types. That way adverts would practically disappear from browsers
instead of showing "site not available" errors where the adverts should
have been. I guess I'll try it out sometime and see.
[color=blue][color=green]
>> Readily available host lists on the Internet that I looked at all have
>> a single 127.0.0.1 address, but it would be easy enough to change the
>> lines as you suggest with a little script - but would that make any
>> difference in practice?[/color]
>
> Yeah - I've seen lists like that, which may contain as many as several
> thousand addresses and address ranges. Most seem to be designed for
> windoze users, and I've no experience with that.
>[/color]

While some of these lists try to stop sites that are known to exploit IE
holes, most of them (as far as I can see) are to stop adverts, tracking,
and other questionable web server behaviour, which applies to any
browser on any OS.
[color=blue][color=green]
>> And would windows clients on the network follow the rules and work
>> with 127.*.*.* addresses? (brief testing suggests yes, but I value the
>> experience of others).[/color]
>
> I would expect so, but have no windoze boxes to test it.
>
> Old guy[/color]

On Tue, 06 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <4730e71b$0$3198$8404b019@news.wineasy.se>, David Brown wrote:
[color=blue]
>Moe Trin wrote:[/color]
[color=blue][color=green]
>> DNS is not the hosts file, and different rules apply. What is often
>> a problem in DNS setups is the accidental use of wild-cards - which
>> mean that all hostsnames _other_than_ those with A records return a
>> 'default' address. Think of a zonefile where there are A records
>> for hosts A.example.com, B.example.com, and C.example.com. If asked
>> about host D.example.com (for which there is no A record), the name
>> server returns a "valid" answer of (for example) 192.0.2.222 -
>> usually because of a '*' character in a hostname record in the zone
>> file (such as '*.example.com IN A 192.0.2.222')
>>
>> See the documentation for your nameserver, as there may be
>> differences.[/color]
>
>I'll check the documentation for dnsmasq.[/color]

I don't use dnsmasq, but I suspect you want to look at the -A option.
You may need to be careful if you are grabbing updates for windoze
systems, as they frequently use a network bandwidth provider such as
akamai to do the actual delivery. There are other applications in
addition to those used by windoze that MAY use a bandwidth provider.
[color=blue]
>The reason I was asking regarding DNS serving is that dnsmasq can
>pre-load names from any files in the same format as /etc/hosts
>(including /etc/hosts itself), and treat these entries as A records.
>This would make it particularly easy to use a ready-made hosts file,
>and would let clients on the network take advantage of the redirection
>without the hassle of updating every client's hosts file, and
>without the slowdown associated with big hosts files on windows.[/color]

That sounds like an ideal candidate for the -A option, but I don't
know how many domains can be included, or if multiple instances of
the -A line are permitted.
[color=blue]
>I've had an idea for improving this too - rather than pointing all
>these advertising servers towards 127.0.0.1 (or 127.x.x.x), I could
>point them towards an internal web server with re-write rules so that
>any requests for a .gif file would return a 1-pixel blank gif, and so
>on for other file types. That way adverts would practically disappear
>from browsers instead of showing "site not available" errors where the
>adverts should have been. I guess I'll try it out sometime and see.[/color]

I think if you search a bit on this concept, you'll see it's been done.
I'm not a web guy, so I don't pay attention to it - most of my web
based activity is done using lynx, and most of the sites I hit don't
have that much advertising.
[color=blue]
>While some of these lists try to stop sites that are known to exploit
>IE holes, most of them (as far as I can see) are to stop adverts,
>tracking, and other questionable web server behaviour, which applies
>to any browser on any OS.[/color]

That doesn't stop stuff where the address is already included as a
dotted-quad, but most of my browsing is done as a user who has a non-
writable home directory (chmod 440). On the occasion when I need to
save something, I can dump it to /tmp.

Old guy

> You're adding another chance for spoofing, unless you are able to[color=blue]
> verify that the host claiming to be 'foo.example.com' really is. You[/color]

AFAIK dnsmasq will always add its domain name to those names, so if the
host requests "foo" he'll get for example "foo.home". I'm not even sure
if "foo.example.com" would be accepted (and turned into
foo.example.com.home) or just rejected, but in any case it doesn't seem
like a big security risk.
[color=blue]
> Very true. It was never designed for that function. But don't forget
> that this was also the era of the Berkeley 'r' commands, and the
> network authentication based on hostnames.[/color]

I believe this is unfair to DHCP: this is a protocol for LANs, not for
the Internet... a very different context. And it's not clear to me what
a safer system could look like anyway.


Stefan

Moe Trin wrote:[color=blue]
> On Tue, 06 Nov 2007, in the Usenet newsgroup comp.os.linux.networking, in
> article <4730e71b$0$3198$8404b019@news.wineasy.se>, David Brown wrote:
>[color=green]
>> Moe Trin wrote:[/color]
>[color=green][color=darkred]
>>> DNS is not the hosts file, and different rules apply. What is often
>>> a problem in DNS setups is the accidental use of wild-cards - which
>>> mean that all hostsnames _other_than_ those with A records return a
>>> 'default' address. Think of a zonefile where there are A records
>>> for hosts A.example.com, B.example.com, and C.example.com. If asked
>>> about host D.example.com (for which there is no A record), the name
>>> server returns a "valid" answer of (for example) 192.0.2.222 -
>>> usually because of a '*' character in a hostname record in the zone
>>> file (such as '*.example.com IN A 192.0.2.222')
>>>
>>> See the documentation for your nameserver, as there may be
>>> differences.[/color]
>> I'll check the documentation for dnsmasq.[/color]
>
> I don't use dnsmasq, but I suspect you want to look at the -A option.[/color]

It's the -H option (or --addn-hosts, which I use in the conf file). I
don't see any -A option.
[color=blue]
> You may need to be careful if you are grabbing updates for windoze
> systems, as they frequently use a network bandwidth provider such as
> akamai to do the actual delivery. There are other applications in
> addition to those used by windoze that MAY use a bandwidth provider.
>[/color]

Yes, it's important to be careful to avoid blocking useful domains that
also host adverts. On the other hand, windows updates often cause more
harm than good, so blocking them might be a good plan!
[color=blue][color=green]
>> The reason I was asking regarding DNS serving is that dnsmasq can
>> pre-load names from any files in the same format as /etc/hosts
>> (including /etc/hosts itself), and treat these entries as A records.
>> This would make it particularly easy to use a ready-made hosts file,
>> and would let clients on the network take advantage of the redirection
>> without the hassle of updating every client's hosts file, and
>> without the slowdown associated with big hosts files on windows.[/color]
>
> That sounds like an ideal candidate for the -A option, but I don't
> know how many domains can be included, or if multiple instances of
> the -A line are permitted.
>[/color]

I didn't see the -A option you mention, but the -H option loads a whole
file, and it's possible to use it many times (thus the downloaded file
would be in addition to the dns / dhcp server's own /etc/hosts and
another list I have for local machines).
[color=blue][color=green]
>> I've had an idea for improving this too - rather than pointing all
>> these advertising servers towards 127.0.0.1 (or 127.x.x.x), I could
>> point them towards an internal web server with re-write rules so that
>> any requests for a .gif file would return a 1-pixel blank gif, and so
>> on for other file types. That way adverts would practically disappear
>>from browsers instead of showing "site not available" errors where the
>> adverts should have been. I guess I'll try it out sometime and see.[/color]
>
> I think if you search a bit on this concept, you'll see it's been done.
> I'm not a web guy, so I don't pay attention to it - most of my web
> based activity is done using lynx, and most of the sites I hit don't
> have that much advertising.
>[/color]

While I've use lynx a few times, I really don't think there are many
others in my company who would be happy with it! I've bullied them all
into using Firefox or Opera, and threatened them with wire cutters (for
their network cables, of course) if they ever use IE, but there's a
limit to my authority :-(
[color=blue][color=green]
>> While some of these lists try to stop sites that are known to exploit
>> IE holes, most of them (as far as I can see) are to stop adverts,
>> tracking, and other questionable web server behaviour, which applies
>> to any browser on any OS.[/color]
>
> That doesn't stop stuff where the address is already included as a
> dotted-quad, but most of my browsing is done as a user who has a non-
> writable home directory (chmod 440). On the occasion when I need to
> save something, I can dump it to /tmp.
>
> Old guy[/color]