One correction: I shouldn't have said: "The RIRs are iffy". It should have been "The IRRs are iffy". A world of difference. I understand the limitations. However, no one is rushing to implement most of the things that folks in this thread are obsessing over: DNSSec, IPV6, sBGP, soBGP. A bizarre assertion was made that only a "few" are implementing SPF, which is demonstrably untrue. Its getting implemented because its easy, not because its complete. This obsession with perfection will (as usual) result in exactly no progress. Folks need to be willing to get 70% of the benefit for 10% of the effort. - Dan On 5/23/05 2:33 PM, "Edward Lewis" <Ed.Lewis@neustar.biz> wrote:
At 14:00 -0400 5/23/05, Daniel Golding wrote:
My reply is mostly tongue-in-cheek. I think it's always healthy to explore alternatives.
Why not do something simple? The in-addr.arpa reverse delegation tree is pretty accurate. We use it for lots of different things. Why not just give IP address blocks a new RR (or use a TXT record) to identify ASN? This solves the biggest problem we have right now, which is stealing of address blocks. It requires little processor overhead, and only a few additional DNS lookups. Its reasonably foolproof.
I'll ignore that you said "(or use a TXT record)". ;)
Without DNSSEC, what does this buy? "Secure" information on a non-secure channel.
If, by "stealing addresses" you mean that the RIR records are changed, then changing the name servers is trivial - changing to servers that have the hijacker's preferred data (or none!).
Why create reliance on more databases? The RIRs are iffy. We rely on DNS right now. Why not keep relying on it? This solution doesn't solve all of our problems, but it does help, its easy, and people will implement it.
Who populates the DNS (well, the .arpa domain)? The RIRs do.
Ok, please start flaming now :)
Brave to make such a request on a Monday afternoon.