On 07/10/2012 01:10 PM, Michael Richardson wrote:
I'm gonna repeat what I said:
>> First, we need a bit of localhost behaviour on the part of secure
>> resolvers to understand that the trust anchor for .local (or
>> .home.lan or... have we even decided that part yet?) is network
>> dependant.
Michael> Even if we only have one .local, or whatever the root is,
Michael> how does that root's key get into clients?
So, it's not just a question, as you observed, of getting the .local
anchor in, but to know *which* .local anchor to use.
They are all valid "from a certain point of view".
("This is not the androids.local you are looking for!")
Yes. As in, enrollment is hard :)
If .local was never signed, but in a homenet-compliant network, instead
returned
foo.local IN CNAME foo.myhouse.something-unique.someisp.net
Just out of curiosity, is there any significance to .someisp.net in
your example? I'd think -- and it's the way I read Brian's note --
that it would stop at .something-unique.
then we are back to how to get a local delegation done.
If you are on your neighbour's wifi, and your fridge is accessible, and
you have the name fridge.michaelthomashouse.something-unique.someisp.net,
then you are set, right?
Assuming that I'm not running a split horizon DNS for my .unique, I
suppose it would be. But that sort of leads to weirdness with local
DNS leakage beyond the homenet. I'm not sure what the working
group thinks about boundaries (my bad most likely), but wouldn't
that be one of them?
I believe that James asked whether integrity of some sort was
needed. I wonder if one practical reason why the answer might be
yes is because without it these phones shifting back and forth between
administrative domains purely for network reasons (eg, better
signal strength) wouldn't be able to know which local namespace
they should resolve from.
Mike
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
