[DNSOP] Greasing in the other direction

Shumon Huque <shuque@gmail.com> Thu, 07 November 2024 16:13 UTC

Return-Path: <shuque@gmail.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 8C3FFC151520 for <dnsop@ietfa.amsl.com>; Thu, 7 Nov 2024 08:13:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 b_NEtz39OoA6 for <dnsop@ietfa.amsl.com>; Thu, 7 Nov 2024 08:13:22 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13041C14CE42 for <dnsop@ietf.org>; Thu, 7 Nov 2024 08:13:22 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id ca18e2360f4ac-83ab21c269eso43802439f.2 for <dnsop@ietf.org>; Thu, 07 Nov 2024 08:13:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730996001; x=1731600801; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=62OZTM541o6XeoJh5NyPxd1ZMhOz2iZV1+QgHHqCM8A=; b=O3lLxKFyilnyj6NChIrUCZlLZ8m1Ksi6O39pIrqUnRTolEItu9SFcp05sFAJ0e2h8k LyV69ECHC0gIOdvkjcuw8e11/aW/i1Aj9Q1gDRvYaZ4FfchAKcb/83tkjr00ru1LWIky dWDRYel2KBpU8elaABR/WAWHMk1EefS6KSqQxrVKJrQ3Tb/abWvP13Lbr9WLP+j+WjB+ 9Y9aFyW15iAJpooBAQWaMSEpy+S6lBH6Q/jlJnbcj8Eb9THib/sjiDZ8+eItLpozwR4A AxjpyP/vB3O6+WxlDNrv6natiAOQpnD25tkuSXtWh8boLnVKkoRnG8aBBgEC+ryFp0zM xfRQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730996001; x=1731600801; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=62OZTM541o6XeoJh5NyPxd1ZMhOz2iZV1+QgHHqCM8A=; b=fxRIG8UBAwo++XfAvWAWO66YQvTETrjr6UIaLBAc4S2mv3acPIyqAPGPVnuU/Ua4bp XRj6jYafq+JGHrGjqHFlWXyjhxdIf8OZeoKQ2DwJSur2TIXsfuJS6Cit88y6q1yO++my YlDwyje8zs6WUrM5LklmD0dFjcbbGWxEW4AfOwfnbHV6RdObWcRQATK0atC2kQsmXDcP RIdAa4M2PagAdEijY8DGKeZBoybUKNukICRu7zp1/TgquWOfxCdXzhm2DgMkzJq878Sc aCaXDXmqKwwNYMXeetNghHoFkOUF/3H0hxNcMUYKc6M5AhEYQg5DgIZVjOiE6C9+nGNb wHjw==
X-Gm-Message-State: AOJu0Yz80t51airFqmQI5X/t9iNTpbYn2CtYOnezmZbMSzO9Qs7qWkiD fLQYmvKNqu6QgJ7AebD8bJ4uEZSuONh5a2cAJ57ZBf7PmFKYihm7WYbaSx2A2zpqpEkyDaIP4dP 5cRH1M++eBnQXyAN9Nlxu2YfKLA7TwfeyBcEyww==
X-Google-Smtp-Source: AGHT+IGzWRNxYejq+JOxLwq0tr5GB+ZMJigobcDSI2ee3jjLE33usoK24U0NnbPiprYWk5N4aO6WNTRVPgJ1istmQSU=
X-Received: by 2002:a05:6602:2c06:b0:83a:bd82:77f with SMTP id ca18e2360f4ac-83b719757c9mr3001560339f.8.1730996000856; Thu, 07 Nov 2024 08:13:20 -0800 (PST)
MIME-Version: 1.0
From: Shumon Huque <shuque@gmail.com>
Date: Thu, 07 Nov 2024 16:13:09 +0000
Message-ID: <CAHPuVdVmNsTWmEq33WytybvmHNVOsQUg01G+i+U1fLp83uXp3g@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd230a062654e997"
Message-ID-Hash: QRBLYIC7CDMMMA4DELBZJLW6V35FRJLT
X-Message-ID-Hash: QRBLYIC7CDMMMA4DELBZJLW6V35FRJLT
X-MailFrom: shuque@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Greasing in the other direction
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pBtQO_GSwGfCXpgftoYPQD2ipLI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Mark, Stephane, and I have had several discussions about greasing this
week, and I thought I'd share some of this on the list, while folks are
paying more attention to IETF121.

The greasing draft currently only talks about greasing initiated by the
resolver or querier. During the hackathon, we have started looking at
greasing the other way -- from DNS responders (e.g. authoritative servers).
This seems potentially a bit more fraught, since the authoritative server
cannot necessarily know what the result of the greasing action was: did the
querier accept the answer with no problems, did it not accept it and retry
other servers, did it not not accept it and just fail, causing a denial of
service to the downstream application, etc. But we think it is probably an
area worth exploring, and would like to treat this topic in the draft. I've
also realized that earlier this year, Roy Arends and I have already done a
form of responder side greasing as part of our early DELEG tests (having
authority servers insert an unexpected new RRtype in referral responses).

Some things a responder could do include: test setting the final DNS header
flag (Z), send back unknown EDNS header flags, options. higher EDNS
versions etc. All of these should in theory be ignored on reception.

Stephane has also proposed that perhaps auth servers could do greasing only
if they see greasing bits from queriers (which may be a bit safer?). Here
is his proposed text:

---

Authoritative name servers
*******************************

Greasing MAY be used by authoritative name servers when they reply to
queries. They MAY use it with EDNS flags, EDNS versions [TODO: see the
question "Need some help in interpreting EDNS version negotiation" on
dnsop] and EDNS option codes.

Unlike the resolvers, the authoritative name servers do not have an
easy way to detect that a reply with greasing caused problems. If a
DNS requestor cannot handle greased replies, it should try with
another name server of the zone but we cannot be sure they will all
try that. And the other name servers may have the same greasing, and
trigger the same issues. Managers of a zone may perform active
measurements to know if their zone works well with greasing, or to
rely on reports by users.

Therefore, greasing by the authoritative name server MUST be disabled
by default. To increase the probability of successful DNS resolution,
greasing SHOULD be at random (see section 6 "Sampled Selection of
Traffic").