On Wed, Apr 07, 2010 at 01:45:01PM -0700, Internet-Drafts(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf