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

[Ted Hardie <Ted.Hardie@nominum.com>]

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.

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. 

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.

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.

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.

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.  That, in turn,
means that normal methods of following data from one protocol to
another (like whois or EPP) will fail.

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.

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.
				regards,
					Ted