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 ?!?