Install DNS mappings based on TLS/IPsec?

[Iljitsch van Beijnum <iljitsch@muada.com>]

One of the problems we may have to solve is a mapping system from an 
identifier to a set of locators, or from a single locator to the full 
set. A straightforward way to do this would be routable IP address -> 
FQDN -> full set of routable IP addresses. Unfortunately, this requires 
that both the forward and reverse DNS trees are populated properly. 
This in itself is somewhat hard (but doable for well-managed sites, if 
not for ad-hoc and "basement multihoming" situations). However, without 
full deployment of DNSSEC this information isn't particularly 
trustworthy.

It occurs to me that there may be an alternative way to make these FQDN 
<-> address mappings available: they can be negotiated as part of the 
IPsec or TLS negotiations. Think about it: TLS already verifies 
ownership of a FQDN, so after that any FQDN -> address mappings that 
are provided are supposedly trustworthy, and more so than information 
learned through unprotected DNS queries.

In many cases, a reverse lookup (address -> FQDN) isn't necessary, but 
if it is, things get more complicated. It's not inconceivable that 
someone would want to override valid reverse mapping information in the 
DNS with invalid information negotiatated with IPsec/TLS. For instance, 
I may have a valid certificate for justforkicks.net and I could tell 
you that the addresses that belong to Google actually map to 
justforkicks.net and then any time Google spiders your website my 
domain name shows up in your logs. Not immediately fatal, but 
problematic nonetheless. This problem can be solved in one of two ways:

1. only allow installing reverse mapping if there aren't any present in 
the DNS
2. only allow installing reverse mapping for addresses that wouldn't 
normally be used for non-MH purposes

An example of the addresses under 2. could be RFC 3041 addresses. Those 
can be used for non-MH purposes, but presumably not for anything that 
would be bothered by injecting false reverse DNS information. I.e. as 
long as people don't use RFC 3041 addresses for anything worth MH 
protection there is no problem. Another choice would be addresses 
derived from EUI-64s with the u/l flag set to global and the group bit 
set. There is currently no reasonable way that such addresses show up 
by accidentt.

I think that such a mechanism would very nicely compliment a NOID-like 
solution, as it effectively removes dependency on the DNS for a large 
number of applications. At the same time, the solution in question can 
be deployed without having to wait for this mechanism to be 
implemented; it can be put to use as soon as it's available, in the 
mean time there's the DNS.