IDNAbis spec

[Erik van der Poel]

I agree that it would be hard to write something about DNAME and bidi
in a protocol. And I'm not going to hold my breath for any operational
advice either. Instead, I will wait and see what we do about it on the
lookup/display side.

I understand that DNAME does not alias the two roots of the subtrees.
I was just saying that if the roots themselves broke the bidi rules,
some tool could warn about that. That tool would not catch any
problems in the subtree. So it wouldn't be very useful.

Erik

On Wed, Nov 4, 2009 at 7:48 AM, Andrew Sullivan <ajs at shinkuro.com> wrote:
> [ccs to people known to be on list are trimmed]
>
> On Wed, Nov 04, 2009 at 07:23:42AM -0800, Erik van der Poel wrote:
>> I was talking about a single DNAME definition, not about other DNAMEs
>> that might enter the picture at some point.
>
> That sounds like operational guidance, not protocol.  "Be careful" is
> not a useful thing to put in a protocol document, even if it's
> perfectly good operational advice.
>
> I think you're right that it'd be nice to put together a set of
> guidelines for what people ought to do when operating IDNA-aware
> zones.  There are several sets of considerations that need to be taken
> into account, and such advice ought indeed to be offered.
>
> The IDNABIS WG is not the forum that should generate that advice:
> hardly anybody here is a DNS operator.  I in fact previously offered
> (in a fit of insanity) to put together a -00 draft outlining such
> advice.  I think it should probably be taken to DNSOP to see if
> there's any interest.  But the response to me (one with which I have
> considerable sympathy) was that it'd be crazy to try to produce
> operational suggestions for a protocol that hasn't made it out of the
> IETF's process yet.
>
>> If somebody were to
>> implement a tool that checks DNAMEs before inserting them into a zone,
>> that tool could check a *single* DNAME against the IDNAbis bidi rules.
>>
>> Here is an example from http://tools.ietf.org/html/rfc2672
>>
>> frobozz.example.  DNAME    frobozz-division.acme.example.
>>
>> When the tool is about to insert this DNAME into the zone, it can
>> apply the bidi rules to the full domain name (which consists of
>> multiple labels, as you can see).
>
> I think you don't fully understand how DNAMEs work.  Your example does
> not alias "frobozz.example." to "frobozz-division.acme.example.",
> because DNAMEs don't alias the owner name where the DNAME appears.
> That DNAME _does_ alias www.frobozz.example to
> www.frobozz-division.acme.example.  It also aliases א1.frobozz.example
> to א1.frobozz-division.acme.example.  In fact, it aliases
> *.frobozz.example.  The problem is to know whether there is in fact
> the label א1 in frobozz-division.acme.example, and without controlling
> both zones, the administrator of frobozz.example doesn't know (and
> can't know unless zone transfer is permitted or
> frobozz-division.acme.example is running DNSSEC with NSEC).  This is
> why there is a problem.  DNAMEs don't do what a lot of people think
> they do.
>
> A
>
> --
> Andrew Sullivan
> ajs at shinkuro.com
> Shinkuro, Inc.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>