Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

Jan Včelák <jv@fcelda.cz> Mon, 10 April 2017 14:16 UTC

Return-Path: <jv@fcelda.cz>
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 23D66129515 for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 07:16:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.98
X-Spam-Level:
X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fcelda.cz
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 Td2U9X3ybbI6 for <dnsop@ietfa.amsl.com>; Mon, 10 Apr 2017 07:16:28 -0700 (PDT)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9530F129506 for <dnsop@ietf.org>; Mon, 10 Apr 2017 07:16:28 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id q26so36086450uaa.0 for <dnsop@ietf.org>; Mon, 10 Apr 2017 07:16:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fcelda.cz; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=7ADWCkZSSqmF5CADalv/xPBPksz8ivShqGlxwKLBg1k=; b=ZoSCd7A/mbDsbxUNf1KLm7f0SAufxR80g9SDkLNivH7nFm9n5P5v7WZ9UMyaeX7kt+ Wi/Vd3GkOflqndUR085pztZWYJn9zyXZnbyzT0XUyu3enDkx7ZxDxdoKGHk4RUVlxrHy gv0cfHGoieOAFLLaFK+JvW9Rq2AKrRKuCsA1k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=7ADWCkZSSqmF5CADalv/xPBPksz8ivShqGlxwKLBg1k=; b=dgqoix1nnhZ2cVCNxAYbiQllg0YgLnpBCXTFkaBA6V+lu8XqpLc3wyrNq5wq1Xg2AW YVrcd9R+Bc+HpPGa7AgUw32+ONLwtMcYZljmJb1mYPO+s6Bnx6g0+8skx30JPwD1bpD4 /aHc2G2903TMapASYrpOn3CjktB1EFD4sHsn7W2+nO2uP0VA+Uic/M6owurPpHY7DWdF 1UObY7H2PvN2Nm35HgnKXMSdwqOE9ja3mKoGN+hUCq8VMSjtXeCO7ZXfwSn2Zp+Ylnjf sQ4UZKDUBj8gUwy0gnTJ87abB5mKvJUaig9b9FpednjunfBE5+i8mZZvNEB1jEO6VR/q fGGA==
X-Gm-Message-State: AN3rC/6G7zfqyZ/2+JpLEd+HMUd0yEQzyURrYtbGmANJLPlz2V0pPWLCuY+CqgW6GWUr1rd9SkWQlXusuX8YAw==
X-Received: by 10.176.3.182 with SMTP id 51mr1580350uau.66.1491833787384; Mon, 10 Apr 2017 07:16:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.33.74 with HTTP; Mon, 10 Apr 2017 07:16:06 -0700 (PDT)
X-Originating-IP: [2001:1ae9:282f:2400:4938:427:61fc:936]
In-Reply-To: <20170407181139.GB66383@isc.org>
References: <20170407181139.GB66383@isc.org>
From: Jan Včelák <jv@fcelda.cz>
Date: Mon, 10 Apr 2017 16:16:06 +0200
Message-ID: <CAM1xaJ-DH35HDT=s+KedndCDL+gki0YaNQtHTJrXDcP4=2AUVg@mail.gmail.com>
Cc: dnsop@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dhJKnM6_wDNgSqUZzpugFY1ruAY>
Subject: Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt
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: Mon, 10 Apr 2017 14:16:30 -0000

On Fri, Apr 7, 2017 at 8:11 PM, Evan Hunt wrote:
> Here's the new ANAME draft I mentioned last week.

Hey, thanks for this one! I support the attempt to define a record
type that would cover the existing vendor-specific types that
synthesize A/AAAA records in zone apex. If this gets adopted by the
vendors, it means possible zone transfers between these providers. On
the other hand, I don't like the part which moves ANAME processing to
resolvers. I'll comment on that separately.

Besides that, The Security Section should warn DNS operators that
ANAME may be misused to leak data from any internal networks the
server is part of. This was so far concern for resolvers, but with
ANAME it may become a concern for authoritative servers as well.

Jan