This business of proxy chains. It seems like it is insoluble. We faced the same problem when we were trying to deal with spam. There is a huge amount of complexity there. I have been thinking about this problem for the past week and I think I have come up with the answer:
None of it matters. To explain, if Alice decides to use DavesDNS.resolv as her resolution service, that is the end of the matter as far as Alice is concerned. There are two possible types of service Dave might provide: 1) Untrusted: Dave returns full DNSSEC paths for all his answers, Alice checks them. In this case, the source of the data Dave supplies is irrelevant as the source of trust is whatever DNSSEC apex is used for validation. 2) Trusted: Dave returns unsigned records and Alice must trust that Dave obtained the records, processed them etc. in accordance with the agreement between Alice and Dave. The point is that Alice ONLY has a relationship here with Dave. How Dave obtains the records is irrelevant. They can be sent by carrier pigeon for all it matters. The internals of how Alice obtains the information is 'black box'. Within any relay structure, there is always a controller who decides which will be the next relay in turn and unless there is a successful MITM attack (in which case we should want to force the connection to ABORT) the control is always with either the sender or the receiver As far as the Internet protocol is concerned, there is always exactly one hop, the point where the client side hands control over to the service side. And this is always the hop that crosses the narrow waist.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy