Randy, Randy Bush writes:
Has anyone benchmarked how long it will take to resolve 50,000 bgp.in-addr's after a line hiccup or a "clear ip bgp *"? -Hank
yes. current production bind can serve over 2,500 per second from a pc. and it is trivial to preload cache. the arithmetic is left as an exercise.
I thought that perceived benefit of using DNS as the back-end database in this particular proposal was the 'dynamic nature' and real-time properties but apparently the data that is used will be just as old or even older as when using IRR data dumps or are you proposing to set all TTLs to 0 ... Besides, why should anybody want to make 50,000 queries, would it not be a whole bit easier to make every few hours signed dumps (whether the data comes from the IRR or DNS) available at the IP registries' ftp sites ... Supporting ftp for router implementations might be a whole bit easier to support. Ooh, and nobody talked about network operators that have to be teached DNS and the fine details of classless reverse delegations ... (In a previous life, I was responsible for the parts of the in-addr.arpa which are managed by the RIPE NCC and configuring DNS seemed to be a non trivial task for a majority of the ISPs). Isn't sending a PGP signed E-mail update to an IRR/IP registry a whole lot easier and less error prone ?!? David K. ---