On Wed, Apr 07, 2010 at 01:45:01PM -0700, Internet-Drafts@xxxxxxxx wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : DNS Transport > Author(s) : G. Barwood > Filename : draft-barwood-dnsext-dns-transport-18.txt > Pages : 12 > Date : 2010-04-07 > > This document describes a new transport protocol for DNS. > IP fragmentation is avoided, blind spoofing, amplification attacks > and other denial of service attacks are prevented. Latency for a > typical DNS query is a single round trip, after a setup handshake. > No per-client server state is required between transactions. > Packets may optionally be encrypted and authenticated. > The protocol may have other applications. Where is this being discussed? Why is SERVERTOKEN 32 bits? Have we not learned yet that 32 bits is not enough? Why does the client's IP address have to be any part of the computation of SERVERTOKEN? Why is the OPCODE 16 bits followed by a 32-bit value? This completely screws up alignment. Where's the 12-byte transaction ID that's mentioned in section 3.1? Is a response paging protocol that requires server state really better than IP fragmentation? I'd rather we have a hash (MAC!) of the message data included in the response, to make it possible to detect attacks on IP reassembly. (The MAC key could just be the SERVERTOKEN or issued by the server when it issues the SERVERTOKEN.) Nico -- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf