Date: Sun, 6 Dec 1998 03:20:18 -0600 (CST) From: Tony Kimball <alk@pobox.com> To: net@FreeBSD.ORG Subject: resolver behaviour Message-ID: <13930.17883.922553.625725@avalon.east> References: <13929.39477.406338.806610@avalon.east> <199812052221.RAA10079@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoth Garrett Wollman on Sat, 5 December:
: <<On Sat, 5 Dec 1998 14:48:34 -0600 (CST), Tony Kimball <alk@pobox.com> said:
:
: > Instead, to the best of my current understanding, the resolver
: > presently returns failure if it encounters a responding nameserver
: > which reports a negative lookup response. This hardly seems
: > appropriate for systems with interfaces on distinct, unconnected
: > networks!
:
: That is what the protocol says it must do.
The network protocol doesn't regulate application behaviour. In this
light, the issue I raise has nothing to do with network protocol, but
with the usability of the resolver API.
: When an authoritative
: NXDOMAIN is received, the search stops immediately.
This is an accurate description of the current behaviour of
gethostby*. I can easily write a routine with functionality which
is superior to that behaviour for the overwhelming majority of
applications, in that it will enable those applications to naively
connect to the remote host to which they are attempting to connect. I
don't know of any application which would be ill-served by this
enhancement, therefore I suggest that it should be incorporated
into libc as default behaviour. Is there any reason why it should not?
That depends on how the enhancements are obtained...
: You need to
: decide which side your machine's stub resolver is supposed to sit on.
Upon reflection, I really don't want to run a nameserver on the
firewall at all. I just want to be able to successfully resolve names
1) on disjoint networks from a common host, and
2) in the presence of nameservers returning bad negative responses.
(a surprisingly common occurence in the present Internet milieu).
One way of doing this is to apply POLA and try the nameservers of
resolv.conf in succession. In order to avoid waiting for timeouts,
I suggested simultaneous queries...
Quoth Gary Palmer on Sat, 5 December:
: Can you say `packet storm'? I knew you could ... All our servers here run
: local nameservers, and only have secondary nameserver entries listed for the
: rare occasions named core dumps. I don't want to go increasing the ammount of
: UDP traffic...
Then I refine my suggestion: Rather than making queries simultaneous,
let them be issued in succession with a configurable pause interval
intervening, and stopping if/when a positive response is recieved.
: Seems your problem is not the resolver, but your nameserver setup.
~99% of the nodes on the Internet are managed by entities with no
control over their DNS environment, which is almost invariably
defective in a variety of ways. I'd like to improve the behaviour
of applications under FreeBSD in this environment, while avoiding any
untoward effects such as the 'packet storm' you describe.
Frankly, the current behaviour is just plain broken: Bum nameservers
too often prevent FreeBSD applications from connecting to extant
hosts on the Internet.
: My guess is
: problems arise from doing lookups on `internal' addresses on `external'
: nameservers?
This is one source of problems, but there are others. Again, the DNS
environment on the Internet as a whole is very poor.
: The correct solution then is to run a nameserver on the firewall,
I think this is only desirable if there exists a network which depends
upon the firewall for nameservice; otherwise, it is a *kludge* to work
around a bug in gethostby*!
: and force it to bind only to 127.0.0.1. You use that in your resolv.conf, and
: teach it enough about the topology to answer properly.
But this only pushes the problem out one level, to named. Archie's
patch then fixes the problem. (I'd like to see that patch in
current!) I'd like to also solve the problem at the first line of
defense, gethostby*, because then it is also solved for non-servers.
Quoth Kevin J. Rowett on Sat, 5 December:
: If one nameserver responses name invalid, another responses with
: an address, which would you consider to be the correct answer?
The address, because it often works. The point is to get the job done.
Any application (if such an application were to exist) which wanted
to assume that a negative reply was valid could rely upon non-default
behaviour in gethostby*.
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?13930.17883.922553.625725>