> On 19 Oct 2015, at 04:10, Tirumaleswar Reddy (tireddy) <[email protected]> > wrote: > > This revision addresses comments from the WG. Main changes are: > * DNSoD now uses port 853 > * Added support for fragmentation and reassembly > * SPKI fingerprint using sha256 > * Raw public key-based authentication and cached Information Extension. > * Updates Polling and Performance considerations Sections. >
Hi, Thanks for this updated draft with more details on the proposed fragmentation solution. This is an initial review as I have 3 major questions at this point. 1) I’m slightly confused as to whether the “shim” layer is a brand new protocol layer that happens to use the same format as a DNS packet for the first 17 bytes, or if this is a request to change to the DNS protocol? In either case the mechanism proposed relies on the first bit of the OpCode field being set to 0 in ’normal’ DNS packets and 1 in DTLS fragmented packets. It is true that no currently assigned OpCode value sets this bit to 1. However, if I have understood correctly this means this proposal would effectively reserve all OpCodes with values 8-15 in the DNS header, since if any in this range were assigned in future this mechanism would fail (such a reservation would require standards action, as outlined in section 2.2 of RFC6895). 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? 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? Regards Sara.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
