Re: [DNSOP] Asking TLD's to perform checks.

Havard Eidnes <he@uninett.no> Wed, 11 November 2015 10:17 UTC

Return-Path: <he@uninett.no>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8EF1A884B for <dnsop@ietfa.amsl.com>; Wed, 11 Nov 2015 02:17:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 rrl0SKJls-Hj for <dnsop@ietfa.amsl.com>; Wed, 11 Nov 2015 02:17:37 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [IPv6:2001:700:1:0:21e:4fff:feed:ced]) by ietfa.amsl.com (Postfix) with ESMTP id A22211A8849 for <dnsop@ietf.org>; Wed, 11 Nov 2015 02:17:37 -0800 (PST)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 7CF593D0B3; Wed, 11 Nov 2015 11:17:35 +0100 (CET)
Date: Wed, 11 Nov 2015 11:17:35 +0100
Message-Id: <20151111.111735.41519120.he@uninett.no>
To: paf@frobbit.se
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <314D2303-5654-4BA3-A190-F658DAF60E31@frobbit.se>
References: <5373DDAB-1ED2-489B-AB62-BA7CF6D3DB48@frobbit.se> <20151111064744.GW18315@mournblade.imrryr.org> <314D2303-5654-4BA3-A190-F658DAF60E31@frobbit.se>
X-Mailer: Mew version 6.6 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/ABYXAIp7QdySdlIrqsi_pDVdRaI>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Asking TLD's to perform checks.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 11 Nov 2015 10:17:42 -0000

>> It may not be possible for everyone to agree on a comprehensive
>> set of 'wrongs' with no omissions, but it should be possible to
>> get consensus on a core set of 'wrongs' that are not controversial.
> 
> Yes and no. I think going for a minimum will be a good goal,
> but for example to have lame delegations must by definition be
> allowed, as some registration policies do require delegation
> (i.e. NS records). So people add NS records in parent zone, but
> nothing responds there.

I think I don't understand the scenario you're sketching up here.
Furthermore, I don't think I understand why you argue that such a
setup must be acceptable.

Does the scenario look like this?

* Client asks to registrar to set up frobbit.se
* Registrar is lazy and doesn't want to set up a separate zone, so
  instead sets up his own fake .se zone where he puts the data for
  frobbit.se, including delegating NS records which points
  towards the servers serving the fake .SE zone.
* Registrar contacts the registry to have frobbit.se registered
  as a delegation

I've heard anectdotal evidence about folks doing that, and being
denied doing so by registry checks because the SOA record comes
out wrong.

But this doesn't create a lame delegation (does it?) so I don't
think I understand what you're saying.

A zone registered with delegation records, but where none of the
name servers respond to queries for the zone does noone any good,
so why must it be acceptable?  Maybe my imagination can't fathom
the reasons why people insist on creating lame delegations.

> Until policy allows registration without delegation, you will
> see lame delegations.

Again, please explain.

Maybe I'm spoiled by our local CC registry insisting on certain
technical checks passing before registration can be allowed to
proceed.  I'm not saying we're without lame delegations, though,
but I think they occur for other reasons (post-registration
changes, badly-managed transisions).

Regards,

- Håvard