On 28. 05. 20 19:47, Joe Abley wrote: > 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.
>From my resolver implementer view, these variants actually _are_ different >protocols which merely share the same wire format and port number. Differences between mentioned protocol manifest itself any time we encounter a network which silently redirects all traffic on port 53 to local resolver. Recursive resolution attempts in such networks fails horribly because the protocols are actually different and fields mean different things. Having said that ... > > 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. I very much agree, we need to clean up this historical mess! Clear split between stub/forwarding/recursive would help a lot. -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
