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