Re: [DNSOP] Redefining name canonicalization

Mark Andrews <marka@isc.org> Fri, 05 May 2017 22:10 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163F4126DC2 for <dnsop@ietfa.amsl.com>; Fri, 5 May 2017 15:10:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP_E0mSPFIXk for <dnsop@ietfa.amsl.com>; Fri, 5 May 2017 15:10:17 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECA4126E64 for <dnsop@ietf.org>; Fri, 5 May 2017 15:10:17 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 285043493AC; Fri, 5 May 2017 22:10:14 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DEA5416004C; Fri, 5 May 2017 22:10:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CC10F16008E; Fri, 5 May 2017 22:10:13 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YDp2sdSHlum4; Fri, 5 May 2017 22:10:13 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7CDE216004C; Fri, 5 May 2017 22:10:13 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 966CE6DECBA9; Sat, 6 May 2017 08:10:10 +1000 (AEST)
To: Florian Weimer <fweimer@redhat.com>
Cc: Bob Harold <rharolde@umich.edu>, dnsop <dnsop@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <24869f89-8335-6ad8-667d-300b852957a1@redhat.com> <CA+nkc8AT00gkd1RdQ21Xws=2iaiAxmT9ChZssiiw2qQ4vj2b=Q@mail.gmail.com> <22dffab8-1459-4074-e519-3fdda0f3ed4f@redhat.com>
In-reply-to: Your message of "Fri, 05 May 2017 16:04:28 +0200." <22dffab8-1459-4074-e519-3fdda0f3ed4f@redhat.com>
Date: Sat, 06 May 2017 08:10:10 +1000
Message-Id: <20170505221010.966CE6DECBA9@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/U6VR8f8TL-aLprZlcp-bGtyxZrM>
Subject: Re: [DNSOP] Redefining name canonicalization
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 May 2017 22:10:19 -0000

In message <22dffab8-1459-4074-e519-3fdda0f3ed4f@redhat.com>om>, Florian Weimer wr
ites:
> On 04/21/2017 05:08 PM, Bob Harold wrote:
>
> > I can understand you wanting a "getfqdn" function to return the FQDN
> (fully
> > qualified domain name) without doing canonicalization.
> >
> > But just so we are clear on the DNS terms,
> > "access.redhat.com" and "access.redhat.com.edgekey.net" are "aliases"
> > "e133.b.akamaiedge.net" is the canonical name.
> >
> > access.redhat.com is an alias for access.redhat.com.edgekey.net.
> > access.redhat.com.edgekey.net is an alias for e133.b.akamaiedge.net.
> > e133.b.akamaiedge.net has address 104.67.69.246
>
> I'm aware of the terminology.
>
> I just think that in terms of RFC 3493, it would make sense to restrict
> the name transformation applied with AI_CANONNAME on the current
> internet, i.e. clarify that here
>
>     If the AI_CANONNAME flag is specified and the nodename argument is
>     not null, the function shall attempt to determine the canonical name
>     corresponding to nodename (for example, if nodename is an alias or
>     shorthand notation for a complete name).
>
> alias does not refer to CNAME chain resolution, but other forms of
> alias processing (like the slightly historic HOSTALIASES processing).

It does mean the end of the CNAME chain.  Just because some people
misuse CNAME rather than requesting their own type to provide a
name to server mapping or using SRV that we should change what the
flag means.

> This would help to address long-standing security issues in name
> canonicalization, e.g. in Kerberos deployments.

If you want the search name, then add a flag to request that and
extend struct addrinfo by adding a pointer at then end of it which
contains the resolution of the search.  Yes, sometimes the contents
of ai_canonname will be the same as ai_<to_be_decided> and sometimes
not.

getaddrinfo and struct addrinfo are designed to be extended like this.

Don't redefine the existing element.

Mark

> Thanks,
> Florian
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org