[dns-operations] Using UDP length field for an id

[George Barwood]

I don't think this would be practical, due to API limitations,
and probably much else.

I also considered, and rejected, using the IP ID, for similar reasons
( client generates random IP ID, server response copies it ).

The IP ID has the advantage that it can protect fragments against spoofing.

There is also the EDNS "Ping" proposal, which is mor epractical,
but which doesn't protect fragments.

However, none of these does anything to protect against amplification
attacks against 3rd parties, which I consider a more serious problem.

I have a draft that aims to solve many of the DNS transport problems at one
go - it has the carrot of low latency for large responses, and defends against
DoS attacks, including amplification attacks.

http://tools.ietf.org/html/draft-barwood-dnsext-dns-transport

My test implementation is at

http://www.george-barwood.pwp.blueyonder.co.uk/DnsServer/

I'm still working on refining the congestion control aspect.
Comments are invited.

George

----- Original Message ----- 
From: "John Kristoff" <jtk at cymru.com>
To: <dns-operations at mail.dns-oarc.net>
Sent: Monday, October 19, 2009 4:44 AM
Subject: [dns-operations] Using UDP length field for an id


> Would there be any interest in a version of UDP, like UDP-Lite, which
> is essentially UDP, but redefines the largely redundant length field in
> the UDP header?  The new version relevant to this group and DNS would
> be to use those 16 bits for an id field.  A hack for you know what.
> 
> Yes, yes, I know - "DNSSEC!", but just wondering if anyone would even
> admit to consider using such a thing if it were available.  And yes I
> realize it would probably be at least a few years before it would show
> up in any stack, just asking.
> 
> John
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>