[DNSOP] Suggestion related to draft-ietf-dnsop-avoid-fragmentation

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 24 March 2021 04:53 UTC

Return-Path: <brian.peter.dickson@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 78F553A211D for <dnsop@ietfa.amsl.com>; Tue, 23 Mar 2021 21:53:04 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJxPFZ6EjATF for <dnsop@ietfa.amsl.com>; Tue, 23 Mar 2021 21:53:01 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 84E503A211B for <dnsop@ietf.org>; Tue, 23 Mar 2021 21:53:01 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id v23so7447430uaq.13 for <dnsop@ietf.org>; Tue, 23 Mar 2021 21:53:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4QcYiAxcZL3PP09A6DM6wfT/L+i8NqGenBJEHCVAiQY=; b=c8fCFd0mhmEFoUAE+YQluuWCht6LoGbMeDlobKZl4FLP6v0ilnKEq87QektfA2wG49 MobhAwAkB7vAgVVxcUj/qod2LNvycG+UWsPGxTDuZ26kp1GXiykVZg4e2mRJnfF6Cw3z xA86jUq21sFolKnwYw/vVdM2FQcF6OcIZAC2BLZEBiY1XUfJmNbRz+3+z8hWIIvul2lh hPFc9AdXrzy0GJEMz+As8Tn6cTzWGXLLel2ltk5oX/TaEwRqy/RLL5/5tXSxM8qswfF9 oUi8ZaMYiJ4ettnRy89yBwTz+etIJ3NtRHd89iK5IMhMi7w8cH6NQ7nmTDCP2bY6PrTe bXgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4QcYiAxcZL3PP09A6DM6wfT/L+i8NqGenBJEHCVAiQY=; b=L3vLWsGPkRHAzb25CDx2+VqK77/BO7IQzOVvDRDkYIyahi7G1KKqY2yErLY9kZvEvh 2S2QiDNaM4uF9aMe/+Ifb6vuhQpvvTQHpZnUCy0ghmFHzQ2chUT2Hp1Hx9PIh1btKkBO Meec+L2VqSjv2qAsDW9JPYFZ99A4glpVCWqcyeTpwxPH3ERLm2X9giqycbTNO9OgU+Lm YQqSkN8e7UpgxBNQnToAr6CjapkF2trkwFbIcvmvdS9nSpFoCSN8wxqJmyVZGIDK51yR T3+sS2q3PtkqtL3rWPcez+DmlULWPtHizfQ70FzsjhHLNTf6veeEvmZCLiYIOtrMyKHA oB/Q==
X-Gm-Message-State: AOAM5332Q6pzxodSj27UcXUM+i0MW3sBpko4CTmFrLXKIFhT+eEFJ1s7 tei+UcSC8wh3LPJTU1oNmIsUP9p/cJ+fW3Pq8w60qDyjEfg=
X-Google-Smtp-Source: ABdhPJwbLAqvfvhi2gkkumVdtkbSYZiI/qnIYKNfbOnpXyIRJb/y5oGqQVsXLaHO44xcVhBwKnYhxM1tOMadyJoFUcc=
X-Received: by 2002:ab0:234f:: with SMTP id h15mr716973uao.114.1616561579641; Tue, 23 Mar 2021 21:52:59 -0700 (PDT)
MIME-Version: 1.0
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 23 Mar 2021 21:52:48 -0700
Message-ID: <CAH1iCipsL5BdX8kznBV8Sfvsbfx2+JfnZdb1T7XGDOCWKjwc8Q@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b64fcf05be41123a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0IEbPFIYBmdqnowcW8JV8KbOPDc>
Subject: [DNSOP] Suggestion related to draft-ietf-dnsop-avoid-fragmentation
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: Wed, 24 Mar 2021 04:53:05 -0000

In my comments regarding section 3.3 of the
draft-ietf-dnsop-avoid-fragmentation,
I alluded to the need for a method of validating a configured DNS UDP
default MTU value,
when a client is starting up, and has been configured to use one or more
resolvers. This test would be performed towards each resolver, as
appropriate.

If this idea is received with support, I'll write it up. It is quite
simple, I believe, and should
be easy to implement.

The short version is, the client requests a packet from the resolver, which
is exactly the
size of the MTU. This means the resolver returns a response which is padded
with data, so that the DNS payload size matches the maximum size allowed
per EDNS0 rules: the minimum of the configured value on the resolver, and
the requested value from the EDNS0 BUFSIZE value.

The suggested record name, class, type is "lorem.ipsum" CH TXT.
The value would be padded with repeated instances of the canonical
"lorem ipsum" text,
in TXT record format, truncated to the correct length to match the
requirements.
(While "quick brown fox" might be similarly suitable, it is frequently used
by test sets, and its presence as payload might cause confusion and errors.)

The resolver would set the DF bit, and if the response is not received, the
client would need to react accordingly. E.g retry, reduce size, iterate
until a response is received.

Feedback on this idea is welcome.

Thanks,
Brian Dickson