Re: tuba and interworking

[Robert L Ullmann <[e-mail]>]

Hi,

I'd like to highlight some of the other issues with using DNS for
an address translation mechanism; Ross has covered the most serious
performance related issue.

I'm not bashing DNS or the translation idea here; just pointing out
things to look at.

Remember that DNS is not a general purpose distributed database.
In particular, the uses of it are in a restricted class:

	1) they are ephemeral, ths DNS translation being repeated
	   for each use. (subject to "peeking" at TTL and caching
	   the result for TTL)

	2) they are robust in the face of incompletely distributed
           information; if two servers give two different answers,
           that doesn't matter

	3) they are at application layer

(1) In the use of the DNS for (say) mail forwarding, the mailer translates
name->MX->name->A and runs one transaction, discarding the temporary
information. In point: the result of the translation is not reflected
in the mail message. (Yes, in the trace, but that isn't used by automatic
mechanism later.)

	Digression: I was involved in the "debate" over how to do
	Internet<-->X.400 mail address translation some years ago,
	arguing for an algorithmic translation. I was "shouted down"
	when pointing this out. The others glibly invoked the idea
	"when the table gets too big, we'll just use DNS" (which
	they are now doing, or trying to do.)

	The problem is that the translation gets recorded in the
	various addresses in a mail message, which can then retain
	that state (whilst sitting in someone's mailbox) for an
	arbitrary amount of time. The use is, therefore, clearly
	outside the DNS architecture. One might choose to change
	the architecture model, but that should be done _willfully_,
	not by unintentional side-effect, and the new model must
        be then used to design in the requisite features in the
	implementation. (Irrevocable records? ;-)

To return to N-layer: one must ask what the effects of retained state
are. For example, what happens to TCP connections, NTP peer relationships,
etc. when the translation changes out from under them.

2) Along similar lines: if a name->A translation is done (as now), for
a TCP connection, the result is used for as long as the connection is
open. As long as the actual address of the host does not change, it
does not matter that other copies of the zone held by other servers
(and various caches) may have different, possibly non-intersecting,
sets of addresses for the same host. (cf IPv7-TP/IX sect 9.1)

3) Note that DNS servers are often set up in the target domain, with
the appropriate glue records. The presumption (if this is thought about
at all :-) is that if the target domain is unreachable, you don't need
the MX, A, etc information anyway.

But what if the target domain is unreachable because the domain servers
are unreachable because the target domain is unreachable?

Before you say: "that's okay, just make sure one of your servers is
(way) outside your domain", think about a transiently-isolated AS, that
has recovered its link-layer connections to the outside world, and is
trying to bring up N-layer. Under load. Without access to any external
domain servers.

(And cf RFC1183 sect 3, and ask yourself what deployment problems might 
have come up with the records described. Also see RFC1383 (which seems 
to have been written without knowledge of 1183 ;-) for more discussion.)

---
Just to think about ...

---
For all these reasons, TP/IX-IPv7 was designed to use a fixed, static
translation algorithm, with one local parameter. (Maybe per-IF, on an
AD border router)

Best Regards,
Robert