[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: Request for Advice on VGRS IDN Announcement]

On tisdag, jan 7, 2003, at 20:29 Europe/Stockholm, Ted Hardie wrote:


Rob, Harald, Ran, and I have also been talking about this, and there
are a couple of issues that have come up in those discussions you
don't mention.
There are probably many things I have not mentioned. As I said, I wanted to fire off the discussion faster than correct.

Architectural items at stake:

1) This scheme puts the data integrity of the DNS at stake by
converting a negative answer to a positive answer.
This is part of "DNS is not for guessing" which also John Klensin has brought up numerous times. It was first discussed when some browsers started adding "www" and "http://"; in front of partial URL's.

2) Predictability is lost because one set of TLDs behaves this
way, but the behavior is neither uniform across TLDs nor
carried into other parts of the DNS.  This means interoperability
is at risk.
It differs between zones. This I think is even worse. .NU has already done similar things for about 2 years now, and that IS a big problem in Sweden. I see it every day.

Interoperability and predictability with DNS is going away.

On the first point, I personally believe that this behavior is a major
protocol error.  There is a set of data in the zone and specified
behavior for queries against that set, and there is a disjoint set of
data excluded from the zone and specified behavior for queries against
that set.  They fail to follow the specification for queries against
the second set.
Correct. My "acceptable proposal" builds on the fact that the result for the end-user will be the same regardless of if the failure is a DNS error or an application layer problem.

But, yes, they do not follow the spec. As others (like .NU) does not follow the spec.

Rob has noted that you can treat this behavior differently, presuming
that they eliminate the second set by including umpteen zillion new
registrations.  If that is the case, then the queries against the new
entries in the first set should follow the same pattern as those for
any other entry in the set.  Traces of queries against this set show
that this is not the case.  Rob's data shows that queries for A
records like www.\248l.com return IP addresses, but that queries for
NS records for \248l.com return NXDOMAIN.  This is not the same
behavior as for the original members of the set.

Good point. Thanks for checking Rob!


Moreover, this appears to be the registry adding the registrations,
not the registrar, and this appears to bypass all the normal
coordination among the registrars and the registry.
I don't know if I want to call these things 'registrations' but the point is 100% correct. It is the registry, not a registrar.

That, in turn,
means that normal methods of following data from one protocol to
another (like whois or EPP) will fail.

Yes.


In addition, this behavior means that the .com and .net zones cannot
be signed according to any of the current proposals for
DNSSEC. Opt-sideways, as Rob calls the proposal which would otherwise
trigger spam filters, is spec'ed for delegation-only zones which
.com and .net are no longer.

LOFL!

Signing these things?


Lastly, I would like to note that parallels between this behavior and
the behavior of specific clients misses an important point: a user or
organization that wishes to comply with the specs can change client
implementations, but they cannot change operators for a zone.  While
I am sympathetic to the concern, I believe we can and should address
the issues related to the operation of the infrastructure separately
from the issues related to client implementations.
Agree completely.

Very good points. Thanks!

I do hope IAB can come to some conclusion fast, as I see questions from for example government in Netherlands (of all places) like "what the h*ll is happening, can the registry for .NL do similar things if we don't control them" (but in Dutch of course).

paf