Date: Mon, 7 Dec 1998 19:22:46 -0600 (CST) From: Tony Kimball <alk@pobox.com> To: net@FreeBSD.ORG Subject: Re: resolver behaviour Message-ID: <13932.31680.79208.663049@avalon.east> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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. : 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. : 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'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. 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. Quoth Don Lewis on Mon, 7 December: : What do you do when the first server returns NXDOMAIN and the second : server doesn't answer? Do you bounce the email because all the responses : that you got were NXDOMAIN? Yes, the net result is NXDOMAIN, and the effect is to bounce the mail. : In the case of connecting to multiple disjoint networks that use split : DNS, I don't believe your scheme is flexible enough. If example.com : lives in network A, and example.org lives on network B, an MX query for : example.org sent to network A's internal servers may well return the : external DNS information (instead of NXDOMAIN) for network B, when in : fact you want the internal DNS information for network B. Your : proposal would accept the undesired DNS information and return it to the : application. I agree. Wes Peter's suggestion appears to address this case well, however. : 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. 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?13932.31680.79208.663049>