Suggestion from Piet Beertema

	Suppose "nslookup" does domain name to adress translation,
	"net" does IP adress to IP net translation and finally
	"connect" gives the connect information about IP networks
	(This information already is in the RIPE DB), then
		connect ( net ( nslookup ( domain name ) ) )
	does what you want.
No, it doesn't. The connect field gives the connectivity
a given network has, partly in "real" connectivity (e.g.
"EU"), partly in "pseudo" connectivity ("RIPE"), but it
doesn't state which the network service providers are nor
nor the order in which these are service providers. And
the latter is extremely important for determining policy
based routing. The least that should be done to treat the
connect field as routing source is to list the mnemonics
that stand for the real service providers in order of
routing preference (for the associated network of course).
However, I don't like this "solution" at all, given the
mix of "real" and "pseudo" connectivity in the connect
field. Besides, a new field could be based an AS numbers
in order of preference, much like the NSFnet policy routing
database does now, making life infinitely easier.

Furthermore I would consider building potentially large
access or other lists for a router in the suggested way,
through massive DNS queries, a crime...

	Don't overload the DB with information (Current size: 7315558 Byte.
	We started with some hundred KB).
It will keep on growing anyway, especially when the RIPE,
NIC and Merit databases get synchronized. Database size
should not be used as an argument to keep out *useful*
and authoritative information.


	Piet