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

Mailman List Mirror (Read Only)
1

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

2

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.

3

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

4

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?

5

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

6

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.

7

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