[19105] in Kerberos_V5_Development
Re: Proposal for using NAPTR/URI records
daemon@ATHENA.MIT.EDU (Nico Williams)
Wed Feb 25 15:04:19 2015
MIME-Version: 1.0
In-Reply-To: <517459789.25699016.1424892239233.JavaMail.zimbra@redhat.com>
Date: Wed, 25 Feb 2015 14:04:02 -0600
Message-ID: <CAK3OfOgx47WKnbEW93AozqhxiKBnhjMQ-DbVFS8OF41xazjM8w@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Wed, Feb 25, 2015 at 1:23 PM, Nathaniel McCallum
<npmccallum@redhat.com> wrote:
>> The other thing is: NAPTR is way too complex a beast, and if URI RRs
>> will do the trick, then please stay away from NAPTR.
>
> By this, do you mean?
>
> 1. Look up SRV.
> 2. If SRV fails, look up URI.
>
> If no, then what?
>
> If yes, then please defined precisely what you do and do not mean by "fails."
I didn't say anything about failure.
Use URI RRs, but not NAPTR. That's my take.
SRV RRs don't fit well because of the lack of a URI scheme (could be
http: or https:, but hopefully just http:) and the lack of a local
part (which can be overcome by using the port number and a fixed local
part, though it will upset some people, and perhaps rightly so). If
SRV RRs are already in use for this use-case, so be it, but URI would
be more fitting for a standard. NAPTR seems a little overwrought for
this use case, and anyways, it's the tool I'd reach for last: when
nothing else will work.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
