Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

Havard Eidnes <he@uninett.no> Wed, 03 May 2023 17:00 UTC

Return-Path: <he@uninett.no>
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 0116BC151546 for <dnsop@ietfa.amsl.com>; Wed, 3 May 2023 10:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uninett.no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akx-E5yLlspE for <dnsop@ietfa.amsl.com>; Wed, 3 May 2023 10:00:42 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2200BC1519B8 for <dnsop@ietf.org>; Wed, 3 May 2023 10:00:39 -0700 (PDT)
Received: from smistad.uninett.no (smistad.uninett.no [158.38.62.77]) by smistad.uninett.no (Postfix) with ESMTP id 87EC043E9A2; Wed, 3 May 2023 19:00:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uninett.no; s=he201803; t=1683133237; bh=VTI6iXP6+jTod9HCEYJ2YQQh/x0lO5Xgp3EzaSLF1DM=; h=Date:To:Cc:Subject:From:In-Reply-To:References:From; b=OlTsrn0SYW9AQ3bhEeNyKx6TyK1hPS3jkAA32ovcRVxNhAINF+lQjmwCj63LIbbp1 OiR/03DScnih+rnOVEyE/qZl4UcgAx+ewrB6ta7SjeX5zXSnpxSHeLsblMJkGN+2rE H17OiaCBroVSQFcOBz5Lb8stEFAl8LSheuT++rwQ=
Date: Wed, 03 May 2023 19:00:37 +0200
Message-Id: <20230503.190037.133211721207906037.he@uninett.no>
To: Edward.Lewis@icann.org
Cc: dnsop@ietf.org, dwessels@verisign.com
From: Havard Eidnes <he@uninett.no>
In-Reply-To: <75B8B29D-0CB3-4409-86DF-285C8CCF6ABC@icann.org>
References: <40C193AF-938C-418F-924E-94F4DD358164@icann.org> <B93A0E80-08F8-4FDB-81C2-47C465D8DDB4@verisign.com> <75B8B29D-0CB3-4409-86DF-285C8CCF6ABC@icann.org>
X-Mailer: Mew version 6.9 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YFZ0Cdd3r3PnlCZpGMzLOOQLH8w>
Subject: Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
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, 03 May 2023 17:00:47 -0000

> A lame delegation is said to exist when a server assumed (by
> the querier) to be authoritative for a zone replies
> non-authoritatively for {any|all} data within the zone.
...
> 3) {any|all} open question...can a server be "partially lame?"

Sadly, yes, ref. suspected load balancers who have been taught
how to reply to A queries, but return empty non-AA answers
(possibly with authority information) when queried for other
record types, such as AAAA, ref.

dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. a

vs.

dig @ns4.bpldns.com. lzd.jshsos.ksyunv5.com. aaaa

(this example came up earlier in the discussion, just repeating
it here as an example)

See the results of querying for "ns" or "soa", they are also
non-AA but with a authority section among others pointing to
itself, similar to the result for the "aaaa" query.

Regards,

- Håvard