Date: Mon, 07 Dec 1998 14:03:50 -0700 From: Wes Peters <wes@softweyr.com> To: alk@pobox.com Cc: net@FreeBSD.ORG Subject: Re: resolver behaviour Message-ID: <366C42B6.F2F7FA0F@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?366C42B6.F2F7FA0F>