General DNS questions

[Matt Simerson]

> -----Original Message-----
> From: Brad Knowles [mailto:brad.knowles at skynet.be]
> Sent: Monday, May 21, 2001 4:15 PM
> To: Kevin Darcy; comp-protocols-dns-bind at moderators.isc.org
> Subject: Re: General DNS questions
> 
> At 6:14 PM -0400 5/21/01, Kevin Darcy wrote:
> 
> >>  How wide is the usage of such hosts in the real world?
> >
> >  You mean, hosts whose system resolvers allow toggling of
> >  recursive-versus-non-recursive? I would say "very low usage",
> >  since I'm not aware of any OS that implements this.
> 
> 	IIRC, Apple does this.  They couldn't be bothered to implement a 
> full nameserver on Macintosh,

Any why should they? That's what servers were for. Mac's were for easily
typing documents that looked pretty. Should we pick on Microsoft for not
including a DNS server with Windows? I don't think so.

> but they didn't want to be stuck with a non-recursive resolver,
> so they struck off on their own separate 
> totally bizarre route and decided to create a recursive resolver. 

A recursive resolver is bizarre? How so? What OS out there doesn't use a
recursive resolver? 

By definition a recursive (or stub) resolver has no concept of the TLD and
doesn't have the intelligence to issue iterative queries or follow
referrals. Therefore, stub resolvers (as MacTCP and Open Transport are)
issue recursive queries, just like nearly every other DNS client does. 

What you might be referring to is a rather neat feature of MacTCP that you
might have mistaken for recursive resolution. You can have MacTCP query one
set of DNS servers for your domain and another set of DNS servers for
another domain, and Yet Another set of DNS servers for the rest of the
world. In the config you had a scrolling list of three fields. One field you
put in a domain name (to search within) and the second contained an IP
address of a server that would answer requests for that domain. A dot
matched any domain and forwarded the recursive _query_ off to the IP address
listed in the field. Split horizon DNS had barely been thought of back in
those days. Heck, back then there was a hosts.txt file for the entire
internet. :-0 One reason that feature was so important to MacTCP was that
the Mac was not normally connected to the Internet. It was typically a
campus Mac on an Appletalk network connected to an MacIP gateway (normally a
Shiva Gatorbox) that connected to the campus Ethernet. 

> Indeed, IIRC the early versions would actually "cache" the data they 
> looked up in a local HOSTS.TXT file, so that they would never again 
> have to go looking for that information.

Nope. I've never even seen such a crazy thing. MacTCP is the beginning of
TCP on the Macintosh series of computers and I've been using MacOS since
before MacTCP was available. The only files MacTCP littered on your system
were MacTCP DNR (a file expected by MacOS 5 and 6 apps) and MacTCP Prep (the
MacTCP config). The hosts file needed to be created by the user (or
sysadmin) if your site used one. It worked exactly as you'd expect except it
was more liberal with syntax than it's successor, Open Transport.

> 	And I have given Garry Hornbuckle *NO* end of grief over this 
> bizarre situation which continues to this very day. 

That is utter nonsense. If you talked to Garry about this I would think he'd
have set you straight a long time ago. A little research on Garry will also
reveal that he was receptive to the suggestions of Mac users (and the
internet community as a whole). The only explanation I can think of is you
giving Garry grief over what you perceived to be a problem which in reality
wasn't and he didn't take the time to explain or point you toward TFM to R.

> Well, at least 
> they stopped completely and totally violating virtually every RFC in 
> existence by caching things in a local HOSTS.TXT file.

They never did. I can't even find any evidence that suggests this. 

Since the days of Open Transport (MacOS 7.1 and higher (circa 1996)) MacOS
has used a standards compliant stub resolver. It works just the way you'd
expect a resolver to work on any reasonable OS (*nix, linux, etc..) in that
it checks the hosts file (System Folder:Preferences:Hosts) and does lookups
to a list of DNS servers for everything else. For a stub resolver, that's
exactly how one would expect it to work. 

Apple did not include an authoritative name server in any version of MacOS
up through MacOS X. They did have MacDNS for a while (which they purchased
from.... drat, the name escapes me) and it worked for a DNS server and
cache. Before I graduated to Unix I had a completely Mac based ISP. :-) Over
the years Apple has offered several "Server's" that included BIND for
serving your DNS data. A/UX would have been the first, then AIX, MkLinux,
and finally MacOS X Server. With MacOS X (as opposed to MacOS X Server), you
can use the supplied named or if you're the hacker type, you can install
your own dns resolver and/or server. The resolver stuff in OS X is much more
interesting because instead of a hosts file it grabs info from the NetInfo
database before consulting DNS. Even that is pretty "standard" these days in
that most resolvers now have a local file for consultation of which
databases (and in which order) to consult for dns.

> 	However, you *CAN* still create a local HOSTS file (they finally 
> dropped the ".TXT" ending

You have got to be thinking of another OS. MacOS has never uses a hosts.txt
file. Mac users from that era would rather have been hauled out in the
streets and trampled to death by herds of killer turtles than to have files
with three character extensions polluting their boot floppy or 20MB hard
drive.

> and indeed you can call it anything you 
> want, so long as you identify it to the OS as a "HOSTS file"), and 
> that local HOSTS file will completely over-ride anything you may 
> happen to want to look up in the DNS.

That part is correct when using Open Transport. You can point OT at any file
that's a properly formatted hosts file and it'll work just fine. Of course,
this is pretty much the same for most *nix servers these days. Some unixen
use a handy /etc/host.conf file to configure how you want resolution (ex:
hosts, nis, netinfo, bind). Maybe you're thinking windows? It's the OS that
monopolized the appending of a silly .xxx extension to every filename.

> 	Indeed, the way that most people on Macintosh are getting around 
> the stupid issue of Gracenote and the CDDB suddenly taking all their 
> hard-earned data that they have laboriously entered into the system 
> and going private (and commercial) with that data, is by having a 
> local HOSTS file that points the name "cddb.cddb.com" and 
> "cddb.cddb.org" and "cddb.cddb.net" over to "freedb.org" instead.

And the same way Linux users, *nix users, and windows users can do it.
Nearly every OS with a TCP stack has provisions for a hosts file (PalmOS
doesn't).
 
> 	A simple, nearly trivial, virus could easily create such a HOSTS 
> file and identify it as such to the OS, and redirect traffic for any 
> site in the world to any place they want....  Imagine www.disney.com 
> being redirected to a website that trafficks in kiddie-porn.

That argument just doesn't hold water. To start with, every OS that uses a
hosts file (MacOS, Windows, Linux, FreeBSD, NetBSD, OpenBSD, BSD/OS,
Solaris, SunOS, IRIX, HP/UX, A/UX, AIX, and the list goes on for a LONG
time) is susceptible to such an attack. So whoopy doo. I would suggest that
MacOS up to and including MacOS 9 is the least vulnerable to such an attack
for a very long list of reasons. 

Furthermore the use of a local "hosts" file is a longstanding tradition on
every platform I can think of and it isn't going to go away very soon. It's
important for quite a few reasons, the least of which are the setting up of
network services and the simple fact that although DNS scales better, it is
not reliable. UDP packets drop, networks blip, and BIND crashes. I use
/etc/hosts on nearly every unix server because it's guaranteed to work when
the rest of the network is thrashing about.

Matt