Subject: [dnsext] CDN RR Type for content distribution

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 10 Feb 2010 14:21:50 +0100

Hi,

Perhaps this idea, which uses DNS to publish a directory (but annotated
for better latency), that puts intelligence towards the edge, is of use.

Some principles:
* privacy respect: final resolver makes choice. This is the resolver
that the (CDN unaware) client sent its query to (and thus gives its IP)
today. (and this resolver decides to use the CDN type).
* can be signed with DNSSEC.  No-one makes your traffic-balanced CDN go
the wrong way by spoofing.
* current caches work (and current authority servers and dnssec signers
work).  Stubs could become smarter to make their own choices (mobility).
* does not look anything like access-control.
* can be used anywhere for any purpose.
* use every bit.

The new CDN RR type has the following in the rdata:
* one octet priority field (priority concept like SRV, MX).
* Then follow a number of sections: lists of servers and then subnets
that should use them, then more servers and subnets.

one octet: number of entries in section, upper bits type of section 0:A
1:AAAA 2:cidr 3:extended.  There can be 63 entries. length 0 is
reserved(do not create, ignore remainder of RR if encountered) for types
0,1,2.

then the entries, A are 4 octets each. AAAA 16 octets each, those are
the destination servers.

The cidr section contains a number of CIDR notation networks:
* one octet: cidr length. High bit flags IPv6.
value=0x7F encodes ipv6 /128 length.
* then a number of octets to encode the prefix ((len+7)/8 octets).
Thus a /16 takes three octets and a /24 four octets.

Section type 3 is followed by one-octet extended-type, for up to 63
elements of that type: client ccTLD codes, AS or GPS ranges... Another
one-byte 'octet-length of this section' makes the extended types future
proof.  It could also hold a domain name as a redirection (and flag if
that redirection should query type CDN again).
* extended type 00 is reserved for even-more-extended section types.
* type 01: list of 2-octet ccTLD labels to match whole countries.
* type 02: state in country by 3-octet values.  Or whatever you need.

In a 1000 octet rdata, you can easily have  (2 ipv4 servers + 10 /24s) =
46 octets, and then twenty more of those. And the last one can contain
20 /8s as a fallback, or servers per continent to avoid intercontinental
ping.

Since the first match counts, specific ones have to be first.

needs text in case no subnet matches.  /0 subnet useful.

use upper 4 bits of priority octet for flags. high-prio:try first.
same-prio:randomize which first.

flag0:contact securely (the CDN requests clients to make secure protocol
connections right away to make secure connections respond fast).  (and
while this secure connection establishment is underway, the client can
query SSHFP or TLSFP or whatnot to validate the connection with,
freezing up when that starts to take too long to come back (to stop
downgrade attacks: timeout and tryagain button). xFP is another draft,
of course).

text for serving CDN unaware clients, no signatures for them.

An idea which is different from yours.  :-)
It could still be bad, but in different ways I presume.  Since there are
no requirements for the solution, I guess this fits it just as well.

Best regards,
   Wouter