Re: [DNSOP] Caching of negative zone (non-authoritative) responses

Ted Lemon <mellon@fugue.com> Mon, 08 July 2019 18:00 UTC

Return-Path: <mellon@fugue.com>
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 D3C11120334 for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 11:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.604
X-Spam-Level:
X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 5yNa8FlukUNN for <dnsop@ietfa.amsl.com>; Mon, 8 Jul 2019 11:00:53 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 01ACD120490 for <dnsop@ietf.org>; Mon, 8 Jul 2019 11:00:01 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id w190so1489983qkc.6 for <dnsop@ietf.org>; Mon, 08 Jul 2019 11:00:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qtrELy7uF/QRgqJa1sRLf9BdAtihmhtu3y7HROAnLZk=; b=QRmOqdz7BOZk6x2ZQSie/EuLhJjYmHU2XiKHNEtcDnriYUoacMKfwyi/pD4P8biCiM 11LscBjknCf2vmtD+uMM82dadD0DJOaQKQpt/CsAjUXQYnqjOFpvWbjEIF68OdDAl64t C415NDSnNoZa5JGff63wpPN2Hpi7wujyL7dt2kofPriAcbTftMsu5CHDZ+0yNwq3TTiT 0vhBX3FolZcwp/xOKqeed/Xe15cHrSvtB+6ovKlB0GeeORWjKYfFonR/jDMT+7BeWMKR BX3ApPt4pTrONhv9t5uOQkGy0rcjDoaJDkw2nYnMb6dTQDx6QTELYW0ZXj9GHNaLtzv1 +ojw==
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=qtrELy7uF/QRgqJa1sRLf9BdAtihmhtu3y7HROAnLZk=; b=fKYmyZu2hvtDNFtlUqYzU9AFaA4AG/y5tQLOP27OW8EL0jRQWmN3zRZ6JGscNwP8yc GdJsYKZKfdQgiO1r4eqiri8sJjrCB6HE8N9dDv+TmykOkSePixlP1mEaO3Op2U2x4itt 7nhOJyPlDNYagUpipMmQ5CLGkohi4K7nBphj2PmTkRdwF8Z6TuJ0pfM0T0XVPc1jFh6s t3/8jptTef1S8jYdFK8gPuycy9H3mnF31/JMM10837WzeK9Me8cVR5/owlyaVZ6rOKHk +PUnMCVDgJH1bVAxw3ofSzIbtQPRJFClnztBRYELwcLdmKcGA4KKBbvgD1pjIkIc8hUH LUSA==
X-Gm-Message-State: APjAAAVzyAuLKlldjex9n42VXajEhYOnNawiYM3v0iWLsMF25GtSZbOI HgxeIKaSMZk/r4uOStbNPxfSxg==
X-Google-Smtp-Source: APXvYqx4qi2P5UpEp0UweljcUpmIOgWvdNk4v+tRBMXHGiQy9zqJTpzyyT+UVrt9ZNzDYEjdTuy5xQ==
X-Received: by 2002:a05:620a:1537:: with SMTP id n23mr14397498qkk.441.1562608800698; Mon, 08 Jul 2019 11:00:00 -0700 (PDT)
Received: from ?IPv6:2001:470:c1a2:1:450d:3b0b:90d3:8924? ([2001:470:c1a2:1:450d:3b0b:90d3:8924]) by smtp.gmail.com with ESMTPSA id v4sm7357375qtq.15.2019.07.08.10.59.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 11:00:00 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <972C2F63-A82B-483D-9257-0FCBDD1C87AB@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DC550833-B3A0-4BBE-99D9-1A19C997FD84"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 08 Jul 2019 13:59:57 -0400
In-Reply-To: <ff45e5bd-eab0-06c0-32c2-3f5dc5fc59da@godaddy.com>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
To: "Michael J. Sheldon" <msheldon@godaddy.com>
References: <BYAPR02MB51900835E25A720BB9BF23C8DBF60@BYAPR02MB5190.namprd02.prod.outlook.com> <4D5516C6-924C-4A88-8EC2-C79DA2B48293@fugue.com> <901d1ddf-bd6a-4c83-4ec4-0c8b5f47d48b@godaddy.com> <B2A16703-4AF4-4CA5-843D-3C3E09866225@fugue.com> <ff45e5bd-eab0-06c0-32c2-3f5dc5fc59da@godaddy.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/brYwtrwdyb1X-dy7LGzcmB2wzgQ>
Subject: Re: [DNSOP] Caching of negative zone (non-authoritative) responses
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: Mon, 08 Jul 2019 18:00:56 -0000

On Jul 8, 2019, at 1:27 PM, Michael J. Sheldon <msheldon@godaddy.com> wrote:
> I agree it's somewhat legit to answer for it, but it's a literal
> maintenance nightmare when you're dealing with a very large number of
> zones. Things like that tend to get put in place, then never removed.

Right, but as I said, it’s dead easy to automate.   It’s only a maintenance nightmare because you haven’t done that automation.   I could write you a python script to do it in a week.   And registrations cost money, which means that they will go away on their own.

> And it still leaves the issue that recursives should not just keep
> hammering the lame delegations when they've gotten a REFUSED response.
> That is a definitive legitimate response, and should be honored for a
> reasonable period of time.

That’s not a solvable problem.  The right solution to this problem is actually to set up a way that the operator of an auth server can signal to the registrar that the delegation is refused.   If you want to spend some effort on process, that’s the place I’d suggest putting it.   Getting every resolver on the Internet to stop doing something that every resolver on the Internet currently does is not likely to actually change what you experience as an operator in the relatively short term.

Also, of course, you mentioned that it didn’t seem legit to respond authoritatively, but if we take REFUSED as an authoritative answer, then that’s not legit either.

BTW, it would also be perfectly legitimate for an authoritative server that doesn’t provide recursion to respond with NXDOMAIN for any query within a domain that’s delegated to it, and this would be quite easy to implement, although perhaps harder than my python script.   Just do the lookup for the delegation, and if it points to you, respond authoritatively.

Although now that I think about this, another problem we’d face here is that DNSSEC would break this completely.   If you have a secure delegation, but don’t have the ability to sign the zone, you can’t respond authoritatively even if the delegation is pointing at your server.   So here the only real fix is at the registrar.