676 lines
25 KiB
Plaintext
676 lines
25 KiB
Plaintext
|
|
|
|
|
|
|
|
|
|
|
|
Network Working Group A. Kumar
|
|
Request for Comments: 1536 J. Postel
|
|
Category: Informational C. Neuman
|
|
ISI
|
|
P. Danzig
|
|
S. Miller
|
|
USC
|
|
October 1993
|
|
|
|
|
|
Common DNS Implementation Errors and Suggested Fixes
|
|
|
|
Status of this Memo
|
|
|
|
This memo provides information for the Internet community. It does
|
|
not specify an Internet standard. Distribution of this memo is
|
|
unlimited.
|
|
|
|
Abstract
|
|
|
|
This memo describes common errors seen in DNS implementations and
|
|
suggests some fixes. Where applicable, violations of recommendations
|
|
from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
|
|
also describes, where relevant, the algorithms followed in BIND
|
|
(versions 4.8.3 and 4.9 which the authors referred to) to serve as an
|
|
example.
|
|
|
|
Introduction
|
|
|
|
The last few years have seen, virtually, an explosion of DNS traffic
|
|
on the NSFnet backbone. Various DNS implementations and various
|
|
versions of these implementations interact with each other, producing
|
|
huge amounts of unnecessary traffic. Attempts are being made by
|
|
researchers all over the internet, to document the nature of these
|
|
interactions, the symptomatic traffic patterns and to devise remedies
|
|
for the sick pieces of software.
|
|
|
|
This draft is an attempt to document fixes for known DNS problems so
|
|
people know what problems to watch out for and how to repair broken
|
|
software.
|
|
|
|
1. Fast Retransmissions
|
|
|
|
DNS implements the classic request-response scheme of client-server
|
|
interaction. UDP is, therefore, the chosen protocol for communication
|
|
though TCP is used for zone transfers. The onus of requerying in case
|
|
no response is seen in a "reasonable" period of time, lies with the
|
|
client. Although RFC 1034 and 1035 do not recommend any
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 1]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
retransmission policy, RFC 1035 does recommend that the resolvers
|
|
should cycle through a list of servers. Both name servers and stub
|
|
resolvers should, therefore, implement some kind of a retransmission
|
|
policy based on round trip time estimates of the name servers. The
|
|
client should back-off exponentially, probably to a maximum timeout
|
|
value.
|
|
|
|
However, clients might not implement either of the two. They might
|
|
not wait a sufficient amount of time before retransmitting or they
|
|
might not back-off their inter-query times sufficiently.
|
|
|
|
Thus, what the server would see will be a series of queries from the
|
|
same querying entity, spaced very close together. Of course, a
|
|
correctly implemented server discards all duplicate queries but the
|
|
queries contribute to wide-area traffic, nevertheless.
|
|
|
|
We classify a retransmission of a query as a pure Fast retry timeout
|
|
problem when a series of query packets meet the following conditions.
|
|
|
|
a. Query packets are seen within a time less than a "reasonable
|
|
waiting period" of each other.
|
|
|
|
b. No response to the original query was seen i.e., we see two or
|
|
more queries, back to back.
|
|
|
|
c. The query packets share the same query identifier.
|
|
|
|
d. The server eventually responds to the query.
|
|
|
|
A GOOD IMPLEMENTATION:
|
|
|
|
BIND (we looked at versions 4.8.3 and 4.9) implements a good
|
|
retransmission algorithm which solves or limits all of these
|
|
problems. The Berkeley stub-resolver queries servers at an interval
|
|
that starts at the greater of 4 seconds and 5 seconds divided by the
|
|
number of servers the resolver queries. The resolver cycles through
|
|
servers and at the end of a cycle, backs off the time out
|
|
exponentially.
|
|
|
|
The Berkeley full-service resolver (built in with the program
|
|
"named") starts with a time-out equal to the greater of 4 seconds and
|
|
two times the round-trip time estimate of the server. The time-out
|
|
is backed off with each cycle, exponentially, to a ceiling value of
|
|
45 seconds.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 2]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
FIXES:
|
|
|
|
a. Estimate round-trip times or set a reasonably high initial
|
|
time-out.
|
|
|
|
b. Back-off timeout periods exponentially.
|
|
|
|
c. Yet another fundamental though difficult fix is to send the
|
|
client an acknowledgement of a query, with a round-trip time
|
|
estimate.
|
|
|
|
Since UDP is used, no response is expected by the client until the
|
|
query is complete. Thus, it is less likely to have information about
|
|
previous packets on which to estimate its back-off time. Unless, you
|
|
maintain state across queries, so subsequent queries to the same
|
|
server use information from previous queries. Unfortunately, such
|
|
estimates are likely to be inaccurate for chained requests since the
|
|
variance is likely to be high.
|
|
|
|
The fix chosen in the ARDP library used by Prospero is that the
|
|
server will send an initial acknowledgement to the client in those
|
|
cases where the server expects the query to take a long time (as
|
|
might be the case for chained queries). This initial acknowledgement
|
|
can include an expected time to wait before retrying.
|
|
|
|
This fix is more difficult since it requires that the client software
|
|
also be trained to expect the acknowledgement packet. This, in an
|
|
internet of millions of hosts is at best a hard problem.
|
|
|
|
2. Recursion Bugs
|
|
|
|
When a server receives a client request, it first looks up its zone
|
|
data and the cache to check if the query can be answered. If the
|
|
answer is unavailable in either place, the server seeks names of
|
|
servers that are more likely to have the information, in its cache or
|
|
zone data. It then does one of two things. If the client desires the
|
|
server to recurse and the server architecture allows recursion, the
|
|
server chains this request to these known servers closest to the
|
|
queried name. If the client doesn't seek recursion or if the server
|
|
cannot handle recursion, it returns the list of name servers to the
|
|
client assuming the client knows what to do with these records.
|
|
|
|
The client queries this new list of name servers to get either the
|
|
answer, or names of another set of name servers to query. This
|
|
process repeats until the client is satisfied. Servers might also go
|
|
through this chaining process if the server returns a CNAME record
|
|
for the queried name. Some servers reprocess this name to try and get
|
|
the desired record type.
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 3]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
However, in certain cases, this chain of events may not be good. For
|
|
example, a broken or malicious name server might list itself as one
|
|
of the name servers to query again. The unsuspecting client resends
|
|
the same query to the same server.
|
|
|
|
In another situation, more difficult to detect, a set of servers
|
|
might form a loop wherein A refers to B and B refers to A. This loop
|
|
might involve more than two servers.
|
|
|
|
Yet another error is where the client does not know how to process
|
|
the list of name servers returned, and requeries the same server
|
|
since that is one (of the few) servers it knows.
|
|
|
|
We, therefore, classify recursion bugs into three distinct
|
|
categories:
|
|
|
|
a. Ignored referral: Client did not know how to handle NS records
|
|
in the AUTHORITY section.
|
|
|
|
b. Too many referrals: Client called on a server too many times,
|
|
beyond a "reasonable" number, with same query. This is
|
|
different from a Fast retransmission problem and a Server
|
|
Failure detection problem in that a response is seen for every
|
|
query. Also, the identifiers are always different. It implies
|
|
client is in a loop and should have detected that and broken
|
|
it. (RFC 1035 mentions that client should not recurse beyond
|
|
a certain depth.)
|
|
|
|
c. Malicious Server: a server refers to itself in the authority
|
|
section. If a server does not have an answer now, it is very
|
|
unlikely it will be any better the next time you query it,
|
|
specially when it claims to be authoritative over a domain.
|
|
|
|
RFC 1034 warns against such situations, on page 35.
|
|
|
|
"Bound the amount of work (packets sent, parallel processes
|
|
started) so that a request can't get into an infinite loop or
|
|
start off a chain reaction of requests or queries with other
|
|
implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
|
|
SOME DATA."
|
|
|
|
A GOOD IMPLEMENTATION:
|
|
|
|
BIND fixes at least one of these problems. It places an upper limit
|
|
on the number of recursive queries it will make, to answer a
|
|
question. It chases a maximum of 20 referral links and 8 canonical
|
|
name translations.
|
|
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 4]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
FIXES:
|
|
|
|
a. Set an upper limit on the number of referral links and CNAME
|
|
links you are willing to chase.
|
|
|
|
Note that this is not guaranteed to break only recursion loops.
|
|
It could, in a rare case, prune off a very long search path,
|
|
prematurely. We know, however, with high probability, that if
|
|
the number of links cross a certain metric (two times the depth
|
|
of the DNS tree), it is a recursion problem.
|
|
|
|
b. Watch out for self-referring servers. Avoid them whenever
|
|
possible.
|
|
|
|
c. Make sure you never pass off an authority NS record with your
|
|
own name on it!
|
|
|
|
d. Fix clients to accept iterative answers from servers not built
|
|
to provide recursion. Such clients should either be happy with
|
|
the non-authoritative answer or be willing to chase the
|
|
referral links themselves.
|
|
|
|
3. Zero Answer Bugs:
|
|
|
|
Name servers sometimes return an authoritative NOERROR with no
|
|
ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
|
|
queried name is valid but it does not have a record of the desired
|
|
type. Of course, the server has authority over the domain.
|
|
|
|
However, once again, some implementations of resolvers do not
|
|
interpret this kind of a response reasonably. They always expect an
|
|
answer record when they see an authoritative NOERROR. These entities
|
|
continue to resend their queries, possibly endlessly.
|
|
|
|
A GOOD IMPLEMENTATION
|
|
|
|
BIND resolver code does not query a server more than 3 times. If it
|
|
is unable to get an answer from 4 servers, querying them three times
|
|
each, it returns error.
|
|
|
|
Of course, it treats a zero-answer response the way it should be
|
|
treated; with respect!
|
|
|
|
FIXES:
|
|
|
|
a. Set an upper limit on the number of retransmissions for a given
|
|
query, at the very least.
|
|
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 5]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
b. Fix resolvers to interpret such a response as an authoritative
|
|
statement of non-existence of the record type for the given
|
|
name.
|
|
|
|
4. Inability to detect server failure:
|
|
|
|
Servers in the internet are not very reliable (they go down every
|
|
once in a while) and resolvers are expected to adapt to the changed
|
|
scenario by not querying the server for a while. Thus, when a server
|
|
does not respond to a query, resolvers should try another server.
|
|
Also, non-stub resolvers should update their round trip time estimate
|
|
for the server to a large value so that server is not tried again
|
|
before other, faster servers.
|
|
|
|
Stub resolvers, however, cycle through a fixed set of servers and if,
|
|
unfortunately, a server is down while others do not respond for other
|
|
reasons (high load, recursive resolution of query is taking more time
|
|
than the resolver's time-out, ....), the resolver queries the dead
|
|
server again! In fact, some resolvers might not set an upper limit on
|
|
the number of query retransmissions they will send and continue to
|
|
query dead servers indefinitely.
|
|
|
|
Name servers running system or chained queries might also suffer from
|
|
the same problem. They store names of servers they should query for a
|
|
given domain. They cycle through these names and in case none of them
|
|
answers, hit each one more than one. It is, once again, important
|
|
that there be an upper limit on the number of retransmissions, to
|
|
prevent network overload.
|
|
|
|
This behavior is clearly in violation of the dictum in RFC 1035 (page
|
|
46)
|
|
|
|
"If a resolver gets a server error or other bizarre response
|
|
from a name server, it should remove it from SLIST, and may
|
|
wish to schedule an immediate transmission to the next
|
|
candidate server address."
|
|
|
|
Removal from SLIST implies that the server is not queried again for
|
|
some time.
|
|
|
|
Correctly implemented full-service resolvers should, as pointed out
|
|
before, update round trip time values for servers that do not respond
|
|
and query them only after other, good servers. Full-service resolvers
|
|
might, however, not follow any of these common sense directives. They
|
|
query dead servers, and they query them endlessly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 6]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
A GOOD IMPLEMENTATION:
|
|
|
|
BIND places an upper limit on the number of times it queries a
|
|
server. Both the stub-resolver and the full-service resolver code do
|
|
this. Also, since the full-service resolver estimates round-trip
|
|
times and sorts name server addresses by these estimates, it does not
|
|
query a dead server again, until and unless all the other servers in
|
|
the list are dead too! Further, BIND implements exponential back-off
|
|
too.
|
|
|
|
FIXES:
|
|
|
|
a. Set an upper limit on number of retransmissions.
|
|
|
|
b. Measure round-trip time from servers (some estimate is better
|
|
than none). Treat no response as a "very large" round-trip
|
|
time.
|
|
|
|
c. Maintain a weighted rtt estimate and decay the "large" value
|
|
slowly, with time, so that the server is eventually tested
|
|
again, but not after an indefinitely long period.
|
|
|
|
d. Follow an exponential back-off scheme so that even if you do
|
|
not restrict the number of queries, you do not overload the
|
|
net excessively.
|
|
|
|
5. Cache Leaks:
|
|
|
|
Every resource record returned by a server is cached for TTL seconds,
|
|
where the TTL value is returned with the RR. Full-service (or stub)
|
|
resolvers cache the RR and answer any queries based on this cached
|
|
information, in the future, until the TTL expires. After that, one
|
|
more query to the wide-area network gets the RR in cache again.
|
|
|
|
Full-service resolvers might not implement this caching mechanism
|
|
well. They might impose a limit on the cache size or might not
|
|
interpret the TTL value correctly. In either case, queries repeated
|
|
within a TTL period of a RR constitute a cache leak.
|
|
|
|
A GOOD/BAD IMPLEMENTATION:
|
|
|
|
BIND has no restriction on the cache size and the size is governed by
|
|
the limits on the virtual address space of the machine it is running
|
|
on. BIND caches RRs for the duration of the TTL returned with each
|
|
record.
|
|
|
|
It does, however, not follow the RFCs with respect to interpretation
|
|
of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 7]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
the minimum TTL value, for that zone, from the SOA record and caches
|
|
it for that duration. This, though it saves some traffic on the
|
|
wide-area network, is not correct behavior.
|
|
|
|
FIXES:
|
|
|
|
a. Look over your caching mechanism to ensure TTLs are interpreted
|
|
correctly.
|
|
|
|
b. Do not restrict cache sizes (come on, memory is cheap!).
|
|
Expired entries are reclaimed periodically, anyway. Of course,
|
|
the cache size is bound to have some physical limit. But, when
|
|
possible, this limit should be large (run your name server on
|
|
a machine with a large amount of physical memory).
|
|
|
|
c. Possibly, a mechanism is needed to flush the cache, when it is
|
|
known or even suspected that the information has changed.
|
|
|
|
6. Name Error Bugs:
|
|
|
|
This bug is very similar to the Zero Answer bug. A server returns an
|
|
authoritative NXDOMAIN when the queried name is known to be bad, by
|
|
the server authoritative for the domain, in the absence of negative
|
|
caching. This authoritative NXDOMAIN response is usually accompanied
|
|
by the SOA record for the domain, in the authority section.
|
|
|
|
Resolvers should recognize that the name they queried for was a bad
|
|
name and should stop querying further.
|
|
|
|
Some resolvers might, however, not interpret this correctly and
|
|
continue to query servers, expecting an answer record.
|
|
|
|
Some applications, in fact, prompt NXDOMAIN answers! When given a
|
|
perfectly good name to resolve, they append the local domain to it
|
|
e.g., an application in the domain "foo.bar.com", when trying to
|
|
resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
|
|
"usc.edu.bar.com" and finally the good name "usc.edu". This causes at
|
|
least two queries that return NXDOMAIN, for every good query. The
|
|
problem is aggravated since the negative answers from the previous
|
|
queries are not cached. When the same name is sought again, the
|
|
process repeats.
|
|
|
|
Some DNS resolver implementations suffer from this problem, too. They
|
|
append successive sub-parts of the local domain using an implicit
|
|
searchlist mechanism, when certain conditions are satisfied and try
|
|
the original name, only when this first set of iterations fails. This
|
|
behavior recently caused pandemonium in the Internet when the domain
|
|
"edu.com" was registered and a wildcard "CNAME" record placed at the
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 8]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
top level. All machines from "com" domains trying to connect to hosts
|
|
in the "edu" domain ended up with connections to the local machine in
|
|
the "edu.com" domain!
|
|
|
|
GOOD/BAD IMPLEMENTATIONS:
|
|
|
|
Some local versions of BIND already implement negative caching. They
|
|
typically cache negative answers with a very small TTL, sufficient to
|
|
answer a burst of queries spaced close together, as is typically
|
|
seen.
|
|
|
|
The next official public release of BIND (4.9.2) will have negative
|
|
caching as an ifdef'd feature.
|
|
|
|
The BIND resolver appends local domain to the given name, when one of
|
|
two conditions is met:
|
|
|
|
i. The name has no periods and the flag RES_DEFNAME is set.
|
|
ii. There is no trailing period and the flag RES_DNSRCH is set.
|
|
|
|
The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
|
|
BIND, but can be changed at compile time.
|
|
|
|
Only if the name, so generated, returns an NXDOMAIN is the original
|
|
name tried as a Fully Qualified Domain Name. And only if it contains
|
|
at least one period.
|
|
|
|
FIXES:
|
|
|
|
a. Fix the resolver code.
|
|
|
|
b. Negative Caching. Negative caching servers will restrict the
|
|
traffic seen on the wide-area network, even if not curb it
|
|
altogether.
|
|
|
|
c. Applications and resolvers should not append the local domain to
|
|
names they seek to resolve, as far as possible. Names
|
|
interspersed with periods should be treated as Fully Qualified
|
|
Domain Names.
|
|
|
|
In other words, Use searchlists only when explicitly specified.
|
|
No implicit searchlists should be used. A name that contains
|
|
any dots should first be tried as a FQDN and if that fails, with
|
|
the local domain name (or searchlist if specified) appended. A
|
|
name containing no dots can be appended with the searchlist right
|
|
away, but once again, no implicit searchlists should be used.
|
|
|
|
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 9]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
Associated with the name error bug is another problem where a server
|
|
might return an authoritative NXDOMAIN, although the name is valid. A
|
|
secondary server, on start-up, reads the zone information from the
|
|
primary, through a zone transfer. While it is in the process of
|
|
loading the zones, it does not have information about them, although
|
|
it is authoritative for them. Thus, any query for a name in that
|
|
domain is answered with an NXDOMAIN response code. This problem might
|
|
not be disastrous were it not for negative caching servers that cache
|
|
this answer and so propagate incorrect information over the internet.
|
|
|
|
BAD IMPLEMENTATION:
|
|
|
|
BIND apparently suffers from this problem.
|
|
|
|
Also, a new name added to the primary database will take a while to
|
|
propagate to the secondaries. Until that time, they will return
|
|
NXDOMAIN answers for a good name. Negative caching servers store this
|
|
answer, too and aggravate this problem further. This is probably a
|
|
more general DNS problem but is apparently more harmful in this
|
|
situation.
|
|
|
|
FIX:
|
|
|
|
a. Servers should start answering only after loading all the zone
|
|
data. A failed server is better than a server handing out
|
|
incorrect information.
|
|
|
|
b. Negative cache records for a very small time, sufficient only
|
|
to ward off a burst of requests for the same bad name. This
|
|
could be related to the round-trip time of the server from
|
|
which the negative answer was received. Alternatively, a
|
|
statistical measure of the amount of time for which queries
|
|
for such names are received could be used. Minimum TTL value
|
|
from the SOA record is not advisable since they tend to be
|
|
pretty large.
|
|
|
|
c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
|
|
and implemented, to allow the primary server to inform
|
|
secondaries that the database has been modified since it last
|
|
transferred zone data. To alleviate the problem of "too many
|
|
zone transfers" that this might cause, Incremental Zone
|
|
Transfers should also be part of DNS. Also, the primary should
|
|
not NOTIFY/PUSH with every update but bunch a good number
|
|
together.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 10]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
7. Format Errors:
|
|
|
|
Some resolvers issue query packets that do not necessarily conform to
|
|
standards as laid out in the relevant RFCs. This unnecessarily
|
|
increases net traffic and wastes server time.
|
|
|
|
FIXES:
|
|
|
|
a. Fix resolvers.
|
|
|
|
b. Each resolver verify format of packets before sending them out,
|
|
using a mechanism outside of the resolver. This is, obviously,
|
|
needed only if step 1 cannot be followed.
|
|
|
|
References
|
|
|
|
[1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
|
|
RFC 1034, USC/Information Sciences Institute, November 1987.
|
|
|
|
[2] Mockapetris, P., "Domain Names Implementation and Specification",
|
|
STD 13, RFC 1035, USC/Information Sciences Institute, November
|
|
1987.
|
|
|
|
[3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
|
|
974, CSNET CIC BBN, January 1986.
|
|
|
|
[4] Gavron, E., "A Security Problem and Proposed Correction With
|
|
Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
|
|
October 1993.
|
|
|
|
[5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
|
|
1537, CWI, October 1993.
|
|
|
|
Security Considerations
|
|
|
|
Security issues are not discussed in this memo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 11]
|
|
|
|
RFC 1536 Common DNS Implementation Errors October 1993
|
|
|
|
|
|
Authors' Addresses
|
|
|
|
Anant Kumar
|
|
USC Information Sciences Institute
|
|
4676 Admiralty Way
|
|
Marina Del Rey CA 90292-6695
|
|
|
|
Phone:(310) 822-1511
|
|
FAX: (310) 823-6741
|
|
EMail: anant@isi.edu
|
|
|
|
|
|
Jon Postel
|
|
USC Information Sciences Institute
|
|
4676 Admiralty Way
|
|
Marina Del Rey CA 90292-6695
|
|
|
|
Phone:(310) 822-1511
|
|
FAX: (310) 823-6714
|
|
EMail: postel@isi.edu
|
|
|
|
|
|
Cliff Neuman
|
|
USC Information Sciences Institute
|
|
4676 Admiralty Way
|
|
Marina Del Rey CA 90292-6695
|
|
|
|
Phone:(310) 822-1511
|
|
FAX: (310) 823-6714
|
|
EMail: bcn@isi.edu
|
|
|
|
|
|
Peter Danzig
|
|
Computer Science Department
|
|
University of Southern California
|
|
University Park
|
|
|
|
EMail: danzig@caldera.usc.edu
|
|
|
|
|
|
Steve Miller
|
|
Computer Science Department
|
|
University of Southern California
|
|
University Park
|
|
Los Angeles CA 90089
|
|
|
|
EMail: smiller@caldera.usc.edu
|
|
|
|
|
|
|
|
|
|
Kumar, Postel, Neuman, Danzig & Miller [Page 12]
|
|
|