Re: [dnsext] a lightweight process for assigning EDNS option codes

[Phillip Hallam-Baker <[e-mail]>]

I think it rather more likely that we end up changing the DNS
client-resolver protocol first.

One of the things I have found playing about with DPLS is that probably the
biggest leverage performance upgrade that can be done is to change the
client resolver protocol so that while a request is still one UDP packet,
the reply can consist of several.

Another thing that I realized is that the cost of transitioning to DNS 1.0
over DPLS (or DTLS) is exactly the same as the cost of transitioning to DNS
2.0 over DPLS. So if people go this route they might as well take the
opportunity to tweak the protocol to fix some of the more irritating
restrictions (e.g. only one request per request packet).



On Sun, Sep 4, 2011 at 9:05 AM, Nicholas Weaver
<[e-mail]>wrote:

>
> On Sep 4, 2011, at 5:39 AM, Phillip Hallam-Baker wrote:
>
> > If EDNS0 codes were ever exhausted it is a trivial matter to generate
> more. Just assign a new extension RR code.
> >
> > I suspect that it won't be a problem though, I can't see how we could run
> out of EDNS codes before RR codes.
>
> You don't even need to do that.  If we reach 50% exhausting of the code
> space, just define the reserved EDNS0 options code of FFFF as "the next 4
> bytes are the extended extended option code", and from that point onward,
> experimental extensions have to use the extended option code space.
>
>


-- 
Website: http://hallambaker.com/