Re: [EAI] Fw: I-D Action: draft-yao-eai-dns-00.txt

[[e-mail]]

> Dear all,

>    This draft was triggered by  email software providers when we discussed the eai implementation with them.
>    Any comments are welcome.

First, I have to say that given the present state of play of the DNS, I am
extremely skeptical that a new RRTYPE can actually deploy soon enough to be
useful. And that's assuming you are able to get it through the process quickly,
which is also unlikely.

Sadly, the DNS folks are in total denial as to the issues and AFAICT see no
value in working on mechanisms that would improve the situation. And even if
this were to change, you're at best talking about improving the situation for
RRTYPEs developed years from now.

Second, the text you have is very confusing; at one point you say the
record returns a list of domains, at another point you imply they are
actually host names. Wordsmithing definitely needed.

Third, if I understand the proposal (and I may not), I also have to say that
the semantics are more than a little ugly. You look up a domain and either get
back "all", which is fine, "no", also fine, or a list of EAI-suppporting hosts
- ick. You are then supposed to intersect that list with the list you get back
from from your MX query, correct? That's going to be a fair bit of work and I
suspect a lot of implementations won't bother.

It would be much better to use SRV for this, making it an alternative to MX for
the EAI case. And it avoids having to compute the intersection; you just
specify the EAI-capable hosts, done. The "all" and "no" case are served by not
having an entry; then you try the MX and either succeed or fail. And SRV has
the huge advantage of being deployed. 

And if you stick with the intersection approach, I don't think a list of domain
names packed into a single string is the way to do it. Multiple records
containing name fields fields are a better bet because they support
compression, and compression can make a big difference when there's lots of
repetition in the names, as seems likely. (I note in passing that you get this
for free with SRV.)

This is also one case where TXT records really do not make sense as an
alternative, again because of compression issues. If you're going to overload
something, overload SRV - it's actually designed to be overload in this way.

				Ned