ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes)

Michael Sinatra michael at rancid.berkeley.edu
Tue Oct 5 15:55:40 UTC 2010


> 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





More information about the NANOG mailing list