On 28 May 2020, at 12:22, Vladimír Čunát <vladimir.cunat+i...@nic.cz> wrote:
> I'm not sure if it would be a net benefit if we consider the added > complexity (like the few unpleasant corner cases), the need to implement > on both sides, and other ways that are available. Is saving the number > of IP-layer packets the only significant motivation? > > For resolver-to-auth case I do suspect some potential. [...] This is a tangent, and not directly related to the topic of packing extra records into an answer section. This general separation of stub-to-resolver and resolver-to-auth use cases seems like it's coming up more often. Another recent example is the question of discovery of available transports (DoT, DoH, etc) for stub-to-resolver is being examined as a separate problem from the same question for resolver-to-auth, which I think is also reasonable. Architecturally, today, we treat those use cases (and others like forwarder-to-resolver, or forwarder-to-forwarder) as all using the same protocol in all the senses of that phrase. Perhaps it's time to look at whether it would be useful to draw some boundaries across what is currently one diagram describing how people look stuff up. It seems to me that there are useful distinctions we could make in response behaviour, for example, depending on whether it's auth-to-resolver or resolver-to-stub. Access control, transport security and privacy and amplification potential also seem like they might be considered differently in different parts of the system. We already have some flags that only mean anything for particular use-cases, like AD that is meaningless in a response from auth to resolver. Maybe we could consider an evolution of the architecture to make it more clear that we can imagine different optimisations being applied to different parts of it. Just a thought. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
