Shannon -jj Behrens wrote:
If A connects to B, and B wishes to pass the connection info
to C, B only has the address with which A accessed B. If A
and B are in the same site and used site-local communication,
and C is not in that site, B does not have enough information
to refer C to A. Hence, your suggestion does not solve this case.
I agree, but is it reasonable for B to tell C to talk to A, or is it
more reasonable for B to tell A to connect to C by the 'name blob' it
would have used to contact C?
Please don't think I am picking on this instance, but the whole mode of
attack by finding a failure case, without thinking through alternatives
is a waste of everyone's time.
Doing otherwise ignores the reality that the
network does not look the same from all points.
I agree, and in fact, that's what I'm asking you how to work around.
See above about changing the message sequence.
...
That's true, and that sufficiently solves one side of the
problem. However,
the other side of the problem is knowing which name resolver
to go to in the first place.
Unless there is some hint in the name string, the only approach I know
of is to shotgun all the servers.
If I use my home resolver, I
won't be able to get the address of
(e.g.) my printer, but if I use my work resolver, I won't be
able to get the
address of my toaster. Do I need to always check both? It
seems that we're encountering this situation because DNS
implicitly assumes (at least in my limited understanding)
that choice of a DNS proxy should not affect the results.
Which is my argument to the IAB: the infrastructure components that pass
around topology information are completely out of step with the reality
of the deployed network topology. We need to fix this because it will
not get better on its own.
...
The fact that SL does not provide multiple concentric
security zones
is not a failure of SL, because that was not a design requirement
(again we need to agree on the problems to be solved).
Well, that's a fair answer.
By the way, I do applaud your effort in making a site-locals
requirements document. I think such a document will
ultimately be useful if it presents requirements in such a
way that people who wish to replace the functionality that
site-locals provide know what needs replacing.
I am not trying to claim I have all the answers, so if anyone has
content for it, please send them.
Tony