Re: [idn] SC/TC equivalence

[Erik Nordmark <Erik.Nordmark@eng.sun.com>]

> Thank you!  One thing that should be considered by anyone contemplating
> server-side equivalence rules is that clients will not know that the
> names are equivalent.  For web browsers, this will affect visited link
> coloring, page caching, cookie permissions, etc.  Similar pitfalls will
> exist in other applications.  Zone administrators willing to tolerate
> such limitations are free to do server-side equivalence matching to
> their heart's content.  It would be ludicrous for this working group to
> try to prohibit this practice, because it's equivalent to populating the
> zone with identical data for all the matching names, which is obviously
> permitted.

I don't think this WG prohibits this - it shouldn't as far as I can tell.
But the ability of the client to tell
that it got the right answer to a DNS query does add some severe constraints.
[I assume DNS protocol experts will correct me if I got thins wrong.]

If the client asks for A and gets a respose with QNAME A' and answer X then how
does the client know that it wasn't spoofed? Applying DNSSEC would just tell
the client that X is indeed the answer to the question for A'.

So unless the server mains records for both A and A' (with their SIGs)
(where A and A' really expand to all the possible combinations as in
the UNAME) then the client needs to verify that A and A'
match.


Thus there seem to be two choices:
 - client sends A to server
 - server folds A to A' (A' := nameprep(A)), looks up A' and responds to client
 - client verifies that A and A' are the same by checking nameprep(A) = A'
   (to prevent being spoofed)

OR
 - client does A' := nameprep(A), sends A' to server
 - server looks up A' and responds to client
 - done

Thus client might as well do the nameprep before composing the query
and save the work in the server.

  Erik