Date: Mon, 07 Dec 1998 23:33:31 -0700 From: Wes Peters <wes@softweyr.com> To: alk@pobox.com Cc: net@FreeBSD.ORG Subject: Re: resolver behaviour Message-ID: <366CC83B.51597443@softweyr.com> References: <13929.39477.406338.806610@avalon.east> <199812052221.RAA10079@khavrinen.lcs.mit.edu> <13930.17883.922553.625725@avalon.east> <3.0.5.16.19981206214053.683794b8@pop.pbdhome.pinboard.com> <13931.34728.540828.941706@avalon.east> <366BF19F.6B8B267E@softweyr.com> <13932.10856.425298.58899@avalon.east> <366C42B6.F2F7FA0F@softweyr.com> <13932.31680.79208.663049@avalon.east>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Kimball wrote:
>
> Quoth Wes Peters on Mon, 7 December:
> : > It would be slightly silly for you to configure your system to
> : > fallback to its original information source, but not completely -- it
> : > would amount to adding a retry.
> :
> : No, it would amount to keeping traffic off the slow link, and provide
> : a backup in case the local caching server is off-line. Redundant, yes,
> : silly, no.
>
> But why fall back to a source already known to provide defective information?
I don't know where the pollution came from, or where it currently lives. It
may just be stale information in my local nameserver cache, while upstream
servers have flushed theirs and will return the correct information.
> : I haven't missed your moving target, just decided, as apparently everyone
> : else has, that it is too much a special case to bother with.
>
> That may well be the case. My experience is at best anecdotal and
> quite possible unrepresentative.
Mine configuration and experience are relatively common for small networks
using dialup links, but it would be hard to characterize anything as
"average" in FreeBSD. ;^)
> : Most of the time when nameservers have bad data, it has little to
> : do with cache pollution and much to do with incompetent management.
> : Such is the case with reverse lookups on my domain right now; the
> : named.boot file has the wrong .IN-ADDR.ARPA domain for my reverse
> : file so it cannot possibly work. Emails to my ISP have netted me
> : zero results. Is this what you're talking about? ;^)
>
> Yes, in part, although I the state of reverse lookup is so bad
> that I'd prefer not to have to address the problem.
So you're not trying to download Netscape with strong encryption?
> : I almost wrote in my last reply that such modifications may be of use to
> : me, as I have a number of machines at my "day job" that are multi-homed
> : and reside on disjoint networks, and have no way of providing DNS services
> : on the internal networks without relying on DNS fallback rules. We
> : currently work around this by using NIS on the main net and placing all
> : of the private hosts in the NIS hosts map, but this is an ugly solution
> : at best.
>
> Perhaps you missed the mail from Archie Cobbs about the forwarding
> zone patch for bind 8 at ftp.whistle.com. It addresses this problem
> in a better way that would any proposal of mine, if you can run named.
I've bookmarked the file he referred to. It's pretty far down my list
right now, but I'll get to it someday.
> : I'd prefer to see some way of giving the resolver a hint that the name
> : you're searching for might be on the private network, rather than
> : shotgunning name servers, but don't see how you'd implement that. Perhaps
> : by using the searchlist and constraining domains to servers, i.e.
> :
> : search foo.com foo.hack freebsd.org
> : nameserver 202.202.202.202 # ns.foo.com
> : nameserver 203.203.203.203 # ns.myisp.com
> : domainserver foo.hack 192.168.204.204 # ns.foo.hack
> :
> : where "foo.hack" is your internal network for software development?
>
> This is a good idea too, better than any of my proposals at addressing
> the bullet item #1 problem, and avoids running named.
> How about just extending the nameserver entry, with an optional
> domain field. The fallback algorithm remains unchanged and
> the change is both forward- and back-compatible:
>
> nameserver 10.0.0.1 .intranet.com
> nameserver 1.1.1.1 .com,.org,.gov,.edu,.int
> nameserver 1.1.1.2 .mil
> nameserver 1.1.1.3 !.intranet.com # fallback for everything but .intranet.com
>
> I'm pretty sure this will pass Vixie.
Better. The nomenclature is reasonable, and downward compatible with current
usage -- no domain name list implies "all domains." I like this. It also
COULD add the possibility of introducing "local top level domains" like .test
and .hack, which could be useful for keeping internal domain names short.
Instead of test.boston.foocorp.com, you could simply create the internal
domain .test at boston, and keep the test host names to two-part FQDNs.
> But I still would like to address bullet item #2, and I don't think
> I've got a solution yet that will pass Vixie.
Praise him, the keeper of DNS purity. If he likes the idea, it's probably
generally useful. ;^)
> : Even if you hack FreeBSD so that it does this, what are you going to
> : do when your boss tells you to make this work with the Windoze,
> : MAC, or other closed-source machine on his desk?
> :
> : I think a better scheme would be to write an application that listens
> : on port 53 and forwards queries to the appropriate server.
>
> Archie's BIND 8 forwarding zones patch does this, and although a
> lighter-weight free cross-platform solution would be better, I don't
> have any motivation to solve the problem for other platforms.
Do the forwarding zones work from the client level, or as a part of the
BIND server. If so, a FreeBSD machine configured with this patch may
provide "zoned" name services for a pile of machines, even ones as
dumb as Win95.
And, as you point out, who cares? People who use Win95 deserve what
they get.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr wes@softweyr.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?366CC83B.51597443>