Michael Sinatra, UCB; what are thoughts around best practices for auth DNS server in ILNP world, and how do you handle updates for locator values to the auth servers when a link changes?
A: you need DNSsec to be running, you make updates, you check authenticity of the update, etc. How will other networks know about the changes.
The initial answer to my question didn't quite get the point of the question, so I followed up. I think ILNP is very interesting because it attempts to create a true I/L split via naming semantics. However, it relies on DNS to do this. Somewhere, there has to be an authoritative DNS server(s) that have the prefix list and preferences for the site. (In ILNP, each host can have its own list of preferred prefixes in the form of L64 records, or they can defer to a site-wide L64 RRset with the LP record.) I acknowledge that this requires a secure dynamic update mechanism (presumably with the border routers doing the updates), and it requires very low ttls to improve convergence. Where this becomes interesting from an operational perspective is when I think about how to address authoritative DNS servers in an ILNP world. The DNS server itself has to be reachable, and the prefix list for the DNS server must be updated when the network topology changes. Hence the question: How should I provision authoritative DNS servers, given that the prefix information is provided via DNS--including the prefix information for the DNS servers themselves--leading to a chicken-and-egg problem. In addition, I would assume that I need something similar to glue records (instead of A or AAAA glue, I need L64 or LP glue). I think one answer would be to have all of my authoritative servers in someone else's network, where they could maintain all of the L64 records completely independent of my DNS infrastructure. With the DNS servers in my network, I don't think there's an answer to the chicken-and-egg problem. Of course, if one of their upstreams dies, my DNS may suffer if I can't withdraw my partner's network's prefixes from the L64 record for my DNS server. This blends into Danny's comment about routing relying on DNS and DNS relying on routing, and to Dave's comment on the binding between the identity and locator being a critical (and difficult) component of the I/L split. I realize that the distinction between operations and protocol development in this discussion may be subject to interpretation, but I also think it's important to understand the operational implications of developing protocols early on. michael