From owner-freebsd-net Mon Dec 7 13:04:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA15332 for freebsd-net-outgoing; Mon, 7 Dec 1998 13:04:27 -0800 (PST) (envelope-from owner-freebsd-net@FreeBSD.ORG) Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA15321 for ; Mon, 7 Dec 1998 13:04:25 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id NAA25468; Mon, 7 Dec 1998 13:03:52 -0800 (PST) Received: from utah.XYLAN.COM by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA00208; Mon, 7 Dec 1998 13:03:56 -0800 Received: from softweyr.com by utah.XYLAN.COM (SMI-8.6/SMI-SVR4 (xylan utah [SPOOL])) id OAA04199; Mon, 7 Dec 1998 14:03:50 -0700 Message-ID: <366C42B6.F2F7FA0F@softweyr.com> Date: Mon, 07 Dec 1998 14:03:50 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 2.2.7-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: alk@pobox.com CC: net@FreeBSD.ORG Subject: Re: resolver behaviour 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tony Kimball wrote: > > Quoth Wes Peters on Mon, 7 December: > : This seems odd, since DNS isn't yet 15 years old. > > Okay, 14 years and 2 months if you want to be pedantic:-). If want to really be pedantic, it wasn't generally fielded until 1991 - 1992 time frame, when support for HOSTS.TXT was dropped. Any reports of errors before that can easily be considered startup problems. > : In most cases, trying all configured nameservers isn't going to net > : anything, since the servers are pretty much heirarchical anyhow. My > : network, which I consider typical, has a local nameserver which is > : secondary for my own network. The primary is at my ISP, which is also > : the second nameserver listed in resolv.conf. My local nameserver is > : configured with my ISP nameserver as the forwarding site. The "fix" > : you have described would be incredibly redundant and would only > : increase traffic on my limited PPP connection. > > 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. > Would adding a retry be "incredibly redundant" and "only increase > traffic". I think that's for you to decide: Configure it if you > wish. I know of no reason to make this behaviour default. > > I don't think your comments apply to my current working proposal, > although the fact that it has evolved through the course of this > thread probably explains why you are missing that moving target. 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. > : You seem to be confusing "nobody cares about what *I think* my problem > : is" with "nobody cares that a problem exists." You have described to > : us a special case, which applies to your custom network and multi- > : homed hosts on disjoint networks, and then expect us to leap to the > : code to fix this problem not encountered by most FreeBSD users? > > I confused you by mentioning two related issues in one email. I > apologize again for doing this. Please allow me to help you > overcome this confusion by being very very explicit: The problem > I described as bullet item 2 is present for everyone who has > no control over their nameservice. This is the majority of users. Hmmm. It would seem that the majority of users then need to mutiny and replace their domain name administrators. I'm not denying this is a problem, just that the idea of coding around the stupidity of the legions of "IT Professionals" out there would be an impossible, never- ending task. > The problem, restated, is this: For reasons which are not always > evident, but probably relating to cache pollution, individual > nameservers have bad data. NXDOMAIN replies occur for valid names. > Applications relying on libc in FreeBSD are thereby prevented from > making necessary connections. The occurrence is rare, but has > become sufficiently annoying to me over time so that I am willing > to fix it. 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? ;^) > I don't expect anyone to write any code, I wish to write it myself. I > do seek constructive dialog regarding the correct way to solve the > problem. > > : Since the problem is not technically difficult to solve, we will > : patiently wait for YOUR patches to review, and then we can discuss > : what is the most constructive way to make them available for other > : FreeBSD users who might need them. > > I'll supply patches when there is a reasonable consensus as to what > the correct solution is, and not before. I believe in analysis > before design before programming, and in peer review at all phases. Ah, now we're making progress. You are probably fighting some baggage found on many FreeBSD lists, where somebody comes up with what they think is a brilliant idea and INSISTS somebody run off and implement it for them. I think you will find that in the future, if you start off by saying "I intend to implement the following behavior, and seek some guidance before doing so" you'll get fewer unfriendly brush-offs. Pardon our density. 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. 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? -- Where am I, and what am I doing in this handbasket? Wes Peters +1.801.915.2061 Softweyr LLC wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message