> On 27 Oct 2015, at 12:06, Tirumaleswar Reddy (tireddy) <[email protected]> > wrote: > > Hi Sara,
Hi Tiru, Thanks for the quick response. > > [TR] Yes. The other alternative would be to set the first three bits in the > Opcode to 1 to identify fragmented response (Opcodes 14 and 15 will have to > be reserved). Reserving 2 Opcodes compared to 8 seems preferable :-) although non-optimal. If the format of the ‘fragmentation’ protocol header were changed to contain all 4 bits of the OpCode field then only a single Opcode would be required which would minimise the impact on DNS. Do you have a name for the new fragmentation protocol to easily distinguish it from DNS in these discussions? DDF (DNS-over-DTLS Fragmentation) seems like the obvious one to me….. FWIIW - I prefer the concept of finding a single mechanism to cater for fragmentation in both UDP and DTLS (for example, https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/ <https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/>) rather than defining a new protocol that ‘resembles’ DNS. But that would require significant protocol development. > > 2) The IANA Considerations section requests assignment of a new DTLS header > (specifically for DNS fragmentation). However isn’t that something that would > have to go via the TLS WG, not DPRIVE? > > [TR] Other WG had defined DTLS extensions in the past (for example > https://datatracker.ietf.org/doc/rfc5764/ > <https://datatracker.ietf.org/doc/rfc5764/> is the outcome of AVT WG) I may be wrong, but in those cases I think the charter of the working group explicitly covered extensions to core protocols, whereas DPRIVE's doesn’t? > > 3) As is pointed out there are still (rare) cases where the proposed solution > could fail and the draft states that if that happens the server MUST set the > TC bit. However there is no statement about what a client should do in that > case. Should it fallback to TLS or TCP? > > [TR] Yes, will add more details in the next revision. Actually this is an optional mechanism isn’t it, so the fallback case will occur if the client chooses not to implement it. And I have just seen the statement in https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00#section-5 on this: “If the DNS sever's response exceeds the EDNS0 value, the DNS server sets the TC (truncated) bit. On receiving a response with the TC bit set, the client establishes a DNS-over-TLS connection to the same server, and sends a new DNS request for the same resource record.” Sara.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
