Dan, On Fri, 9 Oct 2015 10:07:54 -0700 🔓Dan Wing <[email protected]> wrote:
> On 05-Oct-2015 03:48 pm, Ted Hardie <[email protected]> wrote: > > That said, the shim layer proposal seems at first glance to a > > pretty simple extension of the multiplexing mechanics already > > described. That is, you have the QueryID to allow you to > > interleave requests; you use that in demultiplexing responses. If > > you have that and the DNS response in the first DTLS record > > referencing a QueryID indicates truncation, you look for further > > DTLS records referencing the same QueryID, and re-assemble them > > with the first using a sequence number. > > > > Yes, that would require more specification than in the document, > > but it seems like a reasonable approach and it avoid re-starting > > the protocol machinery (which fallback to TLS would do). > > > > Am I missing a complication here? > > I wrote up how to do this fragmentation/reassembly shim layer, and > would like the WG's feedback. I consulted several people on this > idea, who discouraged us from doing a fragmentation/reassembly shim, > so I am reluctant to share this write-up. But the WG appears > interested in analyzing the technical merits of a > fragmentation/reassembly shim. > > One complication, caused by UDP, is the DNS resource record can > change between the initial query and the re-transmitted query, which > means idempotency is lost (from the perspective of the client), > corrupting the reassembled response. To avoid this corruption, Tiru, > Prashanth and I weighed a bunch of ideas and chose a 16-bit Master > Fragment Sequence Number, which is described below. I am lazy and haven't looked at your work below. I will do so later. I would like to point you at a draft that Davey Song and I have been helping Mukund Sivaraman with to do application-layer DNS fragmentation & reassembly: https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/ It's a work in progress, but I think we've at least identified most of the issues. Cheers, -- Shane _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
