ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes)
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
On Tue, 5 Oct 2010, Michael Sinatra wrote:
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).
Isn't glue the answer to your question? Your name servers get their prefixes from the networks they are connected to, and they do dynamic updates to their parent zone as well as their own zone's master. Then other sites can find them using the usual referral chasing. I am assuming that the name server's name is in a zone for which it is authoritative. If not, it doesn't appear in glue so it doesn't need to update the parent zone. This implies that the name a DNS server uses to refer to itself (i.e. the name for which it performs dynamic updates for its prefix) must be used by all NS records that refer to the name server, so that resolvers can find the server's up-to-date prefix recods. This is stricter than is common in the current DNS - for example, the NS records for my domain do not use the names chosen by those servers' admins. I do this because I think in-bailiwick name server names are a good idea. I don't know if or how much DNSSEC might change the balance of opinion in this area. One thing it doesn't change is the quite astounding amounts of transitive trust that can be introduced by outsourcing your DNS including the nameserver names. http://shinobi.dempsky.org/~matthew/dnstrust/graphs/ So I don't think your question is relevant for most zones. It *is* relevant for the root. ILNP will have to come up with a new scheme for the root zone hints. I haven't looked at it in enough detail to see if they already have a plan. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
On Tue, Oct 5, 2010 at 12:18 PM, Tony Finch <dot@dotat.at> wrote:
On Tue, 5 Oct 2010, Michael Sinatra wrote:
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).
Isn't glue the answer to your question? Your name servers get their prefixes from the networks they are connected to, and they do dynamic
If i have my NS in my network, which is 'ILNP enabled' (if there would be such a thing), I think Michael's question is ... how do I tell DNS where my NS is if my NS is moving and doesn't have a single long-lived stable address ? Some of the answer may be: "Don't do that!", or "plan your moves properly, follow rfcXXXX which shows steps and timing to migrate an NS device/pair/set from network attachment point to network attachment point". -chris
On 10/5/10 9:52 AM, Christopher Morrow wrote:
On Tue, Oct 5, 2010 at 12:18 PM, Tony Finch<dot@dotat.at> wrote:
On Tue, 5 Oct 2010, Michael Sinatra wrote:
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).
Isn't glue the answer to your question? Your name servers get their prefixes from the networks they are connected to, and they do dynamic
If i have my NS in my network, which is 'ILNP enabled' (if there would be such a thing), I think Michael's question is ... how do I tell DNS where my NS is if my NS is moving and doesn't have a single long-lived stable address ?
Some of the answer may be: "Don't do that!", or "plan your moves properly, follow rfcXXXX which shows steps and timing to migrate an NS device/pair/set from network attachment point to network attachment point".
If I am multi-homed and my NS is in my ILNP-enabled network, then it is subject to "moving" at any time. If I lose an upstream due to a sudden failure (such as a link failure), then I need to signal that the lost upstream's prefix should no longer be used. This requires a DDNS update to my L64 record(s). The issue is how should I deal with the situation that you need to know the correct L64 record to get to my network (without waiting for a timeout if you try the broken prefix first) and the way to know what the correct prefixes are is to query a nameserver that's in my network. But to get to my network, you need to know the correct L64 record...etc. So I need to keep nameservers out of my network or have the ability to update an L64 "glue" record on-the-fly in the parent (which also implies a very low ttl on the parent L64 glue record). michael
On 10/5/2010 2:03 PM, Michael Sinatra wrote:
The issue is how should I deal with the situation that you need to know the correct L64 record to get to my network (without waiting for a timeout if you try the broken prefix first) and the way to know what the correct prefixes are is to query a nameserver that's in my network. But to get to my network, you need to know the correct L64 record...etc. So I need to keep nameservers out of my network or have the ability to update an L64 "glue" record on-the-fly in the parent (which also implies a very low ttl on the parent L64 glue record).
My recommendation is that you assign multiple networks. I realize this will possibly take the nameservers out of the ILNP space, but it is the effective method. Then you can reference the nameservers by both addresses, and one timing out will still get you to the other. I'm not up to speed on ILNP, but I'd presume that dual addressing would be required for this to handle failures (if you wanted all nameservers to respond at all times). Jack
On 10/5/10 9:18 AM, Tony Finch wrote:
On Tue, 5 Oct 2010, Michael Sinatra wrote:
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).
Isn't glue the answer to your question? Your name servers get their prefixes from the networks they are connected to, and they do dynamic updates to their parent zone as well as their own zone's master. Then other sites can find them using the usual referral chasing.
Which then implies that parent zones must use DDNS, and must enable secure updates from the child (from wherever the child's DDNS updates are sourced). In addition, the LP and/or L64 records must have very low TTLs, which is very different from the way we do glue today.
I am assuming that the name server's name is in a zone for which it is authoritative. If not, it doesn't appear in glue so it doesn't need to update the parent zone.
Yes. That's what I was implying. [snip]
So I don't think your question is relevant for most zones. It *is* relevant for the root. ILNP will have to come up with a new scheme for the root zone hints. I haven't looked at it in enough detail to see if they already have a plan.
My question was essentially whether this has been thought out from the DNS perspective. The root hints are one issue. Having (for example) .com able to accept dynamic updates from foo.com's BGP-speaking border router whenever foo.com's routing changes (i.e. dropping an upstream because a link went down), having very low ttls (<60sec) on L64 "glue" records which must be queried in order to reach the authoritative nameserver, and having the infrastructure be able to keep up with such queries may also be an issue. Does ILNP have a solution/recommendation for this?
On Tue, 5 Oct 2010, Michael Sinatra wrote:
Which then implies that parent zones must use DDNS, and must enable secure updates from the child (from wherever the child's DDNS updates are sourced).
Yes, well if the authentication can be sorted out this would be much better than having to mess around with a registrar's crappy web interface. Authoritative nameservers could automatically ensure that their glue is in sync.
In addition, the LP and/or L64 records must have very low TTLs, which is very different from the way we do glue today.
It's likely that if you have fairly static connectivity you can leave longish TTLS in your DNS, on the knowledge that if there is an outage things will come back with the same setup as before. This will work for multihoming but not mobility. However this requires that higher level protocols have good connection setup code that can try multiple paths concurrently (so you don't have to wait for a timeout if one is down) and good failover support (SCTP?). Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
participants (4)
-
Christopher Morrow -
Jack Bates -
Michael Sinatra -
Tony Finch