On Oct 31, 2011, at 8:09 PM, Michael Richardson wrote: > If the entities are in fact a group who has an internal trust anchor:
They have an entity they trust to make introductions. That's different. > a) if they want to use DNSSEC, it only matters they have DNSSEC > deployed for the part of the reverse zone they use, and that > they have a trusted anchor into that. And if they don't? See below. > b) a really simple way to get secure DNS data is to make every > (gateway) machine a secondary for the zones in question. So in order to participate in this mesh, you need to be a DNS server. That seems a tad onerous. > c) a second way is to simply point the /etc/resolv.conf and/or > the DNS-forwarders to some *set* of internal servers, ideally > authenticated with TSIG... OR, even do it over the single spoke > to hub IPsec tunnel. That only works if the DNS servers are authoritative for zone in question. But... > Finally, if we are talking IPv4, then the internal IPs are likely > RFC1918, and so one can't use the public DNS anyway, so you have to do > either (b) or (c) ANYWAY. It would have been nice if you put this assumption at the beginning of your message. We are *not* only talking IPv4. Further, for IPv4, we are *not* only talking private address spaces. If you want to extend your earlier protocol to handle non-opportunistic tunnel brokering for IPv4-only, private-address-space-only environments, that's great: I suspect that some people will gravitate towards it. But that's not the problem that is being discussed here. --Paul Hoffman _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
