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
What I was thinking of was the "*n[io]" - tag already used. (e.g: *ni: 1=701 2=1800 3=1238 )
(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...
As far as I remember there is a "*di" - tag for domain name entries listing IP adresses used in this domain. Hence no usual "nslookup"!
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*
Don't misunderstand me!! I don't want to keep out *useful* information. I just want to minimize and streamline the DB. Keep the DB as small as possible and join the information on your local machine (NO DNS lookups!).
and authoritative information.
Piet
Arnold