DNS based resolution (long, technical)

["Wachob, Gabe" <gwachob@visa.com>]

I was having one of those lucid showers this morning and got to thinking about DNS-based resolution for naming authorities. This is the concept of using DNS domain names directly instead of abstract names for the naming authority part. x

 

1) I think its sort of hackish, but its a neccesary hack, especially for bootstrapping

 

2) I am not satisfied with our current proposal for disambiguating DNS from other symbolic dot-separated naming authority names. Since the special use of DNS names is really a special case that only appears at the very first slash segment (and only by itself), we should think if there isn't a better way to mark that the naming authority is specified by DNS. Thus, we might say xri:/symbolic.path/local.part and xri://dns.name.com/local.part (ie two slashes signifies DNS-identified naming authority with the right-to-left semantics)

 

3) What does it mean to use a domain name directly (as in the second of the two examples above)? I was thinking that normally, we just want the NAPTR record(s) associated with the full domain name - that matches expectations I think for most folks. When I type in foo.bar.com I would like to do a regular NAPTR query on that domain name. Now, there has been some discussion about not wanting to rely on regular DNS lookup for trust reasons.

 

What I'd propose then is an algorithmic solutoin. Working from left to right, keep on trying to do a full resolution (query=NAPTR) and each time you fail (ie foo.bar.com doesn't resolve), then take the next level part of the domain name (ie bar.com) and perform the NAPTR lookup. Repeat until you find a NAPTR record. Then, go back to the left (ie using foo if bar.com resolves to a NAPTR record) and apply RDDS as normal.

 

4) I was thinking that RDDS might actually be definable as a formal DDDS application. The problem with DDDS is that as you traverse NAPTR records, you are supposed to apply the *entire* original identifier. This breaks with us because we can't make the assumption that each relative part of the naming authority name is aware of all of the identifiers in the left-to-right path before - in other words, each part may not be aware of all the naming authorities which define name-paths pointing to it.

 

What I'm proposing is that we simply run the entire DDDS algorithm (which is very lightweight) on *each part* of the naming authority part. And the starting point for the DDDS algorithm (the domain with the NAPTR record) is defined by the output of the previous run of DDDS on the previous item in the naming authority path.

 

A concrete example. Lets say we are using resolving a.b.c (left to right, outside the #3 case above).

 

We know by community agreement to start DDDS for the top level identifier at zonea.com

 

1) DDDS is applied just on "a"

1a) The zonea.com  NAPTR regex applicaiton gives us  zoneb.com

1b) We are done with DDDS for "a"

 

2) DDDS is applied just on "b"

2a) We know from the output of step 1 to apply the zoneb.com NAPTR regex to "b" which gives us the domain name zonec.com

2b) We are done with DDDS for "b"

 

3) Since c is the terminal identifier in the lookup path (a.b.c), we are now looking for pointers to the local access protocol. These would be present in SRV records associated with zonec.com -- pick the SRV record that matches your needs and perform the local access protocol.

 

Note that we aren't (I think, need input from the DDDS experts here) violating any of the rules of DDDS - we're just redefining the concept of what is being resolved. This would make me sleep better at night.

 

Thanks for your attention. I know this stuff is in depth. I'd like to close on this issue of dns resolution relatively quickly, so any input you might have now would be great.

 

    -Gabe