[Collisions] "controlled interruption" - 127/8 versus RFC1918 space

[David Conrad]

Wayne,

On Jan 10, 2014, at 9:52 AM, Wayne MacLaurin <Wayne at demandmedia.com> wrote:
> If a network is going to leak as a result of our proposal.  It is ALREADY leaking.  At the very least, their DNS queries are leaking.    If DNS is leaking then they are ALREADY subject to all sorts of undefined behaviour from the coffeehsop, home routers etc..   Huge swaths of that business already do DNS interception for security/access or monetization reasons so who knows what’s happening with their data.

I believe one of the issue here is that there is a presumed difference between leaking the DNS query (which I agree is occurring) and leaking a connection attempt.  As I'm sure you're aware, currently, an application that attempts some sort of action with something.<mumble> where .<mumble> isn't delegated will get back an NXDOMAIN and thus, presumably not attempt a connection.  When .<mumble> gets delegated, and in particular, when something.<mumble> has RRsets for the type being queried, a connection of one form or another will likely be attempted.  This opens up a new source of potential information leakage that does not currently exist. The use of 127/8 attempts to minimize that information leakage (modulo theoretical network stacks that are rather stunningly broken). 

> I have to believe that actually providing good feedback and a well defined privacy policy by whomever is running these proposed services is going to be far better than the completely undefined, unknown behaviour that is out there today.

The behavior today is defined: a connection is not (cannot be) attempted.  The behavior post-delegation is indeed undefined.  The question is whether it is better to set up a SiteFinder-like service to attempt to inform folks that they're probably not doing what they think they're doing or interrupt their behavior to encourage them to figure it out on their own. Both have plusses and minuses.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.dns-oarc.net/pipermail/collisions/attachments/20140110/5af722f9/attachment.pgp>