mills@DCN6.ARPA (07/19/86)
Folks, I wondered why it took so long to resolve ISI.EDU names and discovered the following, which I'm sure you will enjoy. A request to resolve A.ISI.EDU sent to [10.0.0.51] (SRI-NIC.ARPA) returns [10.2.0.27], [10.1.33.27], [128.9.0.33], [10.1.0.52] and [128.9.0.32]. The fuzzball namesolver starts cranking on this list and the following nonsense comes back: 16:04:13 Server [10.2.0.27] [responded from address 128.9.0.33] 16:04:18 Server [10.2.0.27] [responded from address 128.9.0.33] 16:04:23 Server [10.2.0.27] [responded from address 128.9.0.33] 16:04:29 Server [10.1.33.27] [no response] 16:04:34 Server [10.1.33.27] [no response] 16:04:39 Server [10.1.33.27] [no response] 16:04:40 Server [128.9.0.33] [responded with requested data [26.3.0.103] Yes, I really mean that the requests to [10.2.0.27] came back, apparently with valid data, but the address in the IP source-address field was [128.9.0.33], which certainly violates the Principle of Least Astonishment. It turns out all three of these addresses belong to VAXA.ISI.EDU, but on different networks, so that host is clearly fuddled. The last buzzard to catch this bug was SRI-NIC.ARPA. Apparently, it bites VAXen too. Hans-Werner Braun reports seeing responses from some servers coming back with [127.0.0.1] in the IP source-address field. That bit of cosmic goofiness would certainly amuse our Martian friends. Dave -------
dave@RSCH.WISC.EDU.UUCP (07/20/86)
Dave Mills writes: >Yes, I really mean that the requests to [10.2.0.27] came back, apparently with >valid data, but the address in the IP source-address field was [128.9.0.33], This appears to be a bug in the 4.2 and 4.3 UDP implementations. Actually, the way that the network interface between user programs and the kernel is defined, there isn't any way to fix this in all cases. This is because a user program can't specify which of the addresses for a host should be used as the source address. I ran across this bug yesterday while making queries to the UDP time service on one of our hosts. The same sort of thing happened, the source address was not the address to which I had sent the query but the other address for that host. My solution to this problem is to recognize all of the addresses for a host. This seems easier than adding yet another version of the "send" system call to 4.3. I don't think this will help in the case of a name server, though. You can't possibly recognize an address you don't know about! dave
ron@BRL.ARPA.UUCP (07/20/86)
It is not necessary to add a new version of the send call, I believe sendmsg allows you to specify an arbitrary source address, but it is a little harder to deal with. -Ron
karels@MONET.BERKELEY.EDU.UUCP (07/21/86)
The previous answer to Dave Mills' observation on the nameserver for A.ISI.EDU requires considerable clarification and correction. Actually, I was going to deny any responsibility on behalf of 4.2 and 4.3BSD UNIX for dealings between a fuzzball and TOPS-20, but a quick check shows that the server for ISI now runs on a 4.2BSD VAX. I guess I'm not off the hook so easily. The previous reply was totally incorrect in its claims about 4.3. However, 4.2 has a serious problem when it comes to the Principle of Least Astonishment when it comes to UDP return addresses. First, a process receiving UDP datagrams (including a server) receives the datagram "from" address, but not the "to" address. Thus, a server can take no action to ensure that the source address of its reply is the same as the destination address of the request on a multihomed host. (The preceeding is still true in 4.3.) Both 4.2 and 4.3 attempt to choose UDP source addresses according to the destination address, but 4.2 makes a somewhat feeble attempt. It uses its address on a network shared with the destination, if any (which is generally correct), but uses its "primary" address for all other destinations. The "primary" address is the address for the first network interface in the system configuration file. VAXA.ISI.EDU could apparently be helped considerably by placing its imp interface first in its kernel configuration table. 4.3 makes a better attempt at choosing source addresses for datagrams (and client-initiated TCP connections). It uses its address on the network through which it routes the packet. However, for the name-domain system, this is not sufficient that name solvers may depend on the server's choice of source address. In particular, if the server is known by multiple addresses, the name solver may or may not use the "closest" address for the server (the address on the network by which the request will arrive). It seems to be reasonably simple to recognize a reply to one's query, however, without depending on the source address of the reply. That is fortunate, as the predominant servers run on hosts that may not use the expected source address for all replies. The comments made by Dave Cohrs about the "UDP bug" concerning inability to specify the source address of a datagram were incorrect. It is possible for the source address to be bound (using the bind system call) before sending the datagram. It would be reasonable for a knowledgeable server to set up one descriptor for each source address in this way. It is actually the system interface for reception of datagrams that is limiting. By the way, the Martian-grams which Dave Mills mentioned (replies from 127.0.0.1) are more difficult to explain. The last wave of attacks were ICMP error messages with that source address that came from a beta 4.3 host. The code to select the ICMP source address was unfinished at the time of the beta release, although I had forgotten that by the time of the attack. The test release thus used the "primary" address, which in 4.3 is the first address set. At one site, the primary address was thus the one used for the loopback, a configuration error that I had not imagined. The error would be much less serious with the released version of 4.3. Seismo appears to still be running the beta test version or a mixture of the two. With either version, the loopback address can be set to any value. To encourage use of officially-assigned addresses, the release contains an unusable definition of the loopback address that must be changed. Mike
dave@RSCH.WISC.EDU (Dave Cohrs) (07/22/86)
Sorry about the mis-info. I didn't realize that 4.3 was that different from 4.3alpha and 4.3beta. Thanks for the clarification. dave