Subject: [DNSOP] request for early feedback: NAPTR or SRV records in top-level domains?

From: Andrew Sullivan <[email-masked]>
Date: Mon, 25 Aug 2008 16:24:08 -0400

Dear colleagues,

<background detail=long-winded>

In the IDNAbis working group, the current proposals alter the way IDN
work.  One important feature of this is a great deal more flexibility
on what might be registered at any domain.  Moreover, the current
proposals allow for local mapping at the client side.  Some of us are
uncomfortable with this plan, but the reasoning behind it is to allow
for flexibility in areas that have been controversial in the past
(many of the controversies occur at layer 9), and to allow the new
protocol not to break the existing "IDNA2003" behaviour.

It is plain, however, that reasonable zone operators will have to
implement several restrictions on what will be allowed to be
registered.  Moreover, it will aid interoperation and user experience
if clients can, in corner cases, learn what rules the server has in
place so that clients can perform mappings consistently.  (Otherwise,
the risk is that different clients will map things differently and end
up with results that are different in important respects, like
resolving differently.)

In what I am increasingly coming to think of as a moment of complete
insanity, I proposed to come up with a mechanism by which clients
could query the policies of a given registry (and remember "registry"
doesn't always mean "TLD" or equivalent) to find out what the
operator's policies are.  That would allow the client to take
meaningful advantage of the local-mapping capability.

</background>

To provide clients with a convenient way of learning about the policy
statements, I think I'll need a facility that I can be fairly sure the
client could use.  One that has occurred to me is the S-NAPTR
approach, as defined in RFC 3958.  My model in that case is roughly
that of IRIS.  (A variant is the simpler SRV record, but the problem
is the same.)

I am aware that there are some who think non-delegation records in
zones at the top level at least are a really bad idea.  (There are
obvious alternatives, of course, such as static lists compiled into
clients, or a static site that is well-known where people can look up
the policy.)  If you have strong feelings about any of these
approaches, and want to share them with me, I'd appreciate an email
about it.  Ideally off-list, I think, since I haven't actually put a
real proposal together, so there are no real technical details to hash
out.

Best regards, and thanks for your indulgence,

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 26 Aug 2008 05:57:52 +0200

> that of IRIS.  (A variant is the simpler SRV record, but the problem

Personally, I think in this case it is better to for example have a  
URI RR (see draft-faltstrom-uri-01.txt) that refer to some XML blob  
where the policy is presented.

_policy._idn.se. IN URI 10 10 "http://www.iis.se/idn/idnpolicy.xml"

> zones at the top level at least are a really bad idea.

This can be resolved by having NS records for _idn.se.

     Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 26 Aug 2008 05:57:52 +0200

Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Aug 2008 08:23:44 -0400

Dear colleagues,

> where the policy is presented.

I should have been clearer.  If I were to go down this path, the point
of the NAPTR or SRV (or now URI, or whatever other kind of) RR would
actually be just to provide the place to look up the policy (and maybe
how), rather than to provide the policy itself.  I'm not quite as
stupid as I look: I didn't think I was going to put the whole policy
in the DNS itself!

Sorry for any confusion.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Aug 2008 08:23:44 -0400

Dear colleagues,

Sorry for any confusion.

A

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 26 Aug 2008 14:53:54 +0200

> stupid as I look: I didn't think I was going to put the whole policy

Oh, I did get *that* point :-) We know each other enough.

I just wanted to say that I think such URI based solution is better  
than the S-NAPTR or NAPTR one.

But maybe the question was whether that kind of solution was braindead  
to begin with?

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 26 Aug 2008 14:53:54 +0200

Patrik

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Aug 2008 09:07:07 +0200

On Mon, Aug 25, 2008 at 04:24:08PM -0400,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 61 lines which said:

> Moreover, it will aid interoperation and user experience if clients
> can, in corner cases, learn what rules the server has in place so
> that clients can perform mappings consistently.

That's precisely a flaw of IDNAbis: it pushes (may be requires) client
applications to get information about registry policies. (With
registry != TLD.) Can you imagine what the DNS would look like if we
had to look up AFNIC policy to make sense of foobar.gouv.fr?

> I proposed to come up with a mechanism by which clients could query
> the policies of a given registry

Whatever the exact mechanism used (DNS + S-NAPTR, whois, HTTP,
whatever), it will be brittle, it will require "due diligence" from
registries (each time the policy is modified, do not forget to modify
this file), it will raise issues of caching (and of availability if we
do not use the DNS).

These problems are quite similar to the various "suffix list"
proposals.

> One that has occurred to me is the S-NAPTR approach, as defined in
> RFC 3958.

I personnally do not have a problem with this technical choice.

> zones at the top level at least are a really bad idea.

I disagree with them.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Aug 2008 09:07:07 +0200

I disagree with them.