Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

Joe Abley <jabley@hopcount.ca> Thu, 30 July 2020 20:43 UTC

Return-Path: <jabley@hopcount.ca>
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 D30323A0CA1 for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 13:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 uc5Zu07mEBdY for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 13:43:41 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 86DE43A0CA0 for <dnsop@ietf.org>; Thu, 30 Jul 2020 13:43:41 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id b79so26875326qkg.9 for <dnsop@ietf.org>; Thu, 30 Jul 2020 13:43:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=InddE5VlmqunGB49mDCo1imkx/Kwzm8ym5P1QCUKuQA=; b=L6fbiGA5wqAl+V7nEStpEa7uLGO+XnP3qbFzrc4Fylr4dU2mtXc/4Da8M3q4UI3x27 80M9oWdckmlKXOl1iHAVnNFuIXGZ3spMfeSbuOHwUplb/jwsmBy5UiHn9iZSzB/5+pkL K9JDvX2le1+tgMCD/qk0g6j5vI7sOyRD56tIs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=InddE5VlmqunGB49mDCo1imkx/Kwzm8ym5P1QCUKuQA=; b=EbDSJjTcluquVlbdjkTLUKjkUYA21HcV5bBqUIyMnyy+wnle2UmFBJhdGX7lBMnIia G2kIQ7MlsC65PvymEb31qSdYBF1hsG1zKnXvfBgwxUeU4gntP/33a0KounnS5FYPFsLC kW/znRntntSwNevdmB6Lbf2QK4uQ+dUqQJmUfX+mTGKZkduIeSOGXPefcpmUff/eL3xB TZikjTeqkgHCva2kwzfDkM4KRDOXti/VgN2Ja40CD+eOWpDXQ49XNZa4RksgKiPBTARv cOea81e3LmGEkMpELteFNn+nDX0EArGc2GnWdQgU31z3CC/3VDB46KRsTgfZXKOIuHvy h9Ig==
X-Gm-Message-State: AOAM530DAs4PO0h5/HtzL7EkxOImIrF6ieiFPdcCAEmESk4B4soEIbRT 37PxuY8ddFHcm7jRWa9YWoVQl1JdcRcQ3A==
X-Google-Smtp-Source: ABdhPJzpRD9mqymokip+/t8kBXGiOqB3ivrH7Yg6BVhDmy/Gi1CLEvuy7SqggAg60GR1SSMBOZPT4A==
X-Received: by 2002:a37:7bc7:: with SMTP id w190mr1045396qkc.230.1596141820302; Thu, 30 Jul 2020 13:43:40 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e784:c7:cc64:e39d:b3f2:81cb? ([2607:f2c0:e784:c7:cc64:e39d:b3f2:81cb]) by smtp.gmail.com with ESMTPSA id m17sm6368132qkn.45.2020.07.30.13.43.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Jul 2020 13:43:39 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <FA4E316A-E42C-4653-8B92-C505F28E7FD2@hopcount.ca>
Content-Type: multipart/alternative; boundary="Apple-Mail=_42B0A8B6-DD88-40F4-AE29-85BD83CA1EFE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Thu, 30 Jul 2020 16:43:38 -0400
In-Reply-To: <alpine.LRH.2.23.451.2007301630050.418549@bofh.nohats.ca>
Cc: dnsop <dnsop@ietf.org>
To: Paul Wouters <paul@nohats.ca>
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz> <alpine.LRH.2.23.451.2007301253530.416340@bofh.nohats.ca> <F16107A1-669C-41AD-9F59-1794C64B0737@hopcount.ca> <alpine.LRH.2.23.451.2007301446380.418549@bofh.nohats.ca> <31548781-6B30-4198-810F-32245590C7D6@hopcount.ca> <alpine.LRH.2.23.451.2007301630050.418549@bofh.nohats.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/t7u2EDvWciZdSdZn7g7HVbsRDJg>
Subject: Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 30 Jul 2020 20:43:44 -0000

On 30 Jul 2020, at 16:36, Paul Wouters <paul@nohats.ca> wrote:

> On Thu, 30 Jul 2020, Joe Abley wrote:
> 
>>> The .org is definately what I would call a
>>> delegation-only domain. Now let's examine the corner case you have
>>> and see if/what we can do.
>> 
>> OK. Note that it's not a corner case, however; there are many thousands of examples of this and although I haven't examined every single serial that has ever been published, it seems entirely plausible that that there has never been an ORG zone published since 2002 which has been delegation-only.
> 
> 50 domains in a few million is a corner case :)

There are some 20,000 examples in the ORG zone, of which at least 7,000 are due to the domain suspension mechanism I gave as an example. There are lots of well-functioning domains that would fail if all of those A/AAAA records suddenly stopped resolving.

>>> So you are saying that if ns1.example.org serves another-example.org
>>> and example.org is suspended for abuse, that you will still service
>>> A records for ns1.example.org and NS records for another-example.org
>>> containing ns1.example.org but no NS records for example.org? In
>>> the hopes that another-example.org keeps working?
>> 
>> That also seems quite imprecise. Here's a more specific worked example to make sure we understand each other.
>> 
>> $ORIGIN ORG.
>> 
>> BADDOMAIN NS ...
>> BADDOMAIN NS ...
>> NS1.BADDOMAIN A 192.0.2.1
>> 
>> GOODDOMAIN NS NS1.BADDOMAIN.ORG.
>> GOODDOMAIN NS ...
>> 
>> If BADDOMAIN.ORG is suspended (or if the domain is suppressed for some equivalent reason) then the zone cut betwen ORG and BADDOMAIN.ORG will be removed (the BADDOMAIN.ORG NS set will disappear) but the A record above will remain, since it is linked to another domain, GOODDOMAIN.ORG, that depends upon it. Without a zone cut, that makes the ORG servers authoritative for the A record.
> 
> That is exactly what my "quite imprecise" text said :)

No, your imprecise text used had hostnames serving domains and A records being serviced. Those could mean any number of things.

> Although please clarify what you do if there are DS records for
> BADDOMAIN.ORG and/or GOODDOMAIN.ORG

There should be none for BADDOMAIN.ORG <http://baddomain.org/> in that example, but there may be for GOODDOMAIN.ORG <http://gooddomain.org/>.

>> To a certain extent, this behaviour is a consequence of (a) the venerable operaetional need to suspend domains because they have been implicated in abuse and (b) the EPP data model used in the ORG registry, which itself has its origins in the RRP data model used before the re-delegation of ORG to PIR in 2002. As such, it's tempting to assert that the behaviour is a contractual requirement shared with all other gTLDs that are operated subject to the same contract that exists between PIR and ICANN, hence my question about applicability.
>> 
>>> Wouldn't that already fail with DNS servers like unbound with:
>>> 
>>> 	harden-glue: yes
>>> 	harden-dnssec-stripped: yes
>>> 	harden-below-nxdomain: yes
>>> 	harden-referral-path: yes
>>> 
>>> which is the default in Fedora / RHEL / CentOS and maybe others?
>> 
>> If so, that sounds like a problem with Fedora/RHEL/CentOS. To the best of my knowledge, this has been the way that ORG has operated for the past 18+ years.
> 
> Clearly not many people are querying for BADDOMAINS.ORG, or they are
> afraid to contact you?

Well, I don't know that that's clear. I think it's fair to say that the majority of queries we receive at the ORG servers do not come from unbound servers (they come from operators that we know do not run unbound), so the other way of phrasing what you said is that most people who are querying for BADDOMAINS.ORG <http://baddomains.org/> will have no problem at all, even if the specific cases of queries handled by unbound with that specific configuration are handled differently.

> Also, you seem to claim that it is normal and accepted that one should
> trust unsigned glue records from a parent for your delegation and that
> confirming these records at the child is something that you count on
> people not doing?

I'm not sure where you think I'm making a claim of any kind. I'm simply pointing out what happens on the actual Internet.


Joe