Re: Install DNS mappings based on TLS/IPsec?

[Brian E Carpenter <brc@zurich.ibm.com>]

Iljitsch,

Are you suggesting that the multi6 solution should have a strict
dependency on using TLS or IPSEC?

   Brian

Iljitsch van Beijnum wrote:
> 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.