Re: [idn] Re: Optional & Additional Character Equivalence Preparations by Zone

["Edmon" <edmon@neteka.com>]

So, at the end of the day, we point back to DNS Sec which creates the
problem.
I understand and know that there are potential problems but there are
possible solutions as well.  I think there are still a number of outstanding
issues in DNS Sec anyway.  So if this does create a potential issue,
shouldnt we raise the issue instead of shy away from it just because?  Is
this a positive engineering design practice?
Therefore, please dont say that it is not possible and advertise it as such
just like that.  It is possible but we just need to also take care of the
DNS Sec potential issues.
One of the possibility obviously is signing on the fly (perhaps less
advisable), the other the use of opt-in (still in progress... problematic
domains will have to opt-out), and thirdly to have sig rrs for all
permutations (readily possible).  There are more possibilities I believe, we
just need to document them for the implementor to choose from or advise one
particular method.  Afterall, I think it is important that we have a
standardized set of options to deal with the problem at hand (which is
perceived character equivalancy) and it should be within the DNS, but not
necessarily affecting the overall protocol.
With by Zone optional charprep mechanisms, we can achieve this.
Edmon


----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>
To: "Edmon" <edmon@neteka.com>; "Masahiro Sekiguchi" <seki@jp.fujitsu.com>;
"IETF-IDN" <idn@ops.ietf.org>
Sent: Wednesday, January 23, 2002 3:10 PM
Subject: [idn] Re: Optional & Additional Character Equivalence Preparations
by Zone


> --On 2002-01-23 13.19 -0500 Edmon <edmon@neteka.com> wrote:
>
> > But caching servers only cache the result of a query.
> > for example a domain request
> > <A><A'>.example
> > the .example ns would internally match it with
> > <a><a>.example
> > and reply with a positive response.
> > the caching server will therefore cache
> > <A><A'>.example
> > with the response.
> > If you are asking what happens if another request comes:
> > <a><A'>.example
> > then the answer is simple, it will consult the .example server again,
> > then it will cahce
> > <a><A'>.example
> > with the response.
> > So, I dont see why all the servers in the world needs to be able to
handle
> > all additional matching rules.
>
> It's not that easy. The result coming back is called an RR-Set, which
means
> all records which have the same owner. The responses are always treated in
> groups of RR-Sets.
>
> Now, given that we have one RR-Set which has different content on an
> authoritative server from a caching server, read your favourite RFC's
about
> DNS Security.
>
> Just don't go there.
>
>      paf
>
>