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" <[EMAIL PROTECTED]> To: "Edmon" <[EMAIL PROTECTED]>; "Masahiro Sekiguchi" <[EMAIL PROTECTED]>; "IETF-IDN" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >
