Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt

Jan Včelák <> Wed, 01 July 2020 09:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BDA673A0CF4 for <>; Wed, 1 Jul 2020 02:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nxjYXPU7cQ1q for <>; Wed, 1 Jul 2020 02:42:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFFC53A0CF2 for <>; Wed, 1 Jul 2020 02:42:01 -0700 (PDT)
Received: by with SMTP id t27so15519812ill.9 for <>; Wed, 01 Jul 2020 02:42:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ZXjJRAtDxyHeCwUYBEGKzEMjI/TZurdV0ZQTxSKtB5E=; b=dWU2WmkAFwQAeDgxLFkEE+eKjl1b5JCPgGbM34Yk9HvxD536kZJcREb4XIuGSyVQVf huNR6yLrlAuNM2ccWaLdP2xJfzk+5UMvQsnCRRBQJRS0cfHHuelT8p+v79bQkcthS1Hy CSLkZY6GgJl0p92MiaxF3FZiVL3y8I5CTNT0I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ZXjJRAtDxyHeCwUYBEGKzEMjI/TZurdV0ZQTxSKtB5E=; b=EMPAmYZgOKeRLvVB5dhTGHdeBOzdBGCO7wVrvmf8V0CpAX5GqPZ2tc5Di1VWQ8G1kH YGjJa2/tLVnr2M0KU4LHeLlFMp86VlbbdPwo3IzoqYYLEpFH1TzPswZ2TM32+yYkZ0KZ dhIO6Y9GpRvwCVUTwyUbxeCrbUFKU+OngR/699jCYKaGYYyBAsAro2FavKmpjyAWUmtE gZuYmYiaJ82qrJYORwZFOiYiwrKaU1Dx3pFNbWTdWfVl5Jm9c/6iuWjG2IDlMmCf3v5C qzbxrSMgol6UPcemUhZZer2nF5xD/q3XM1vYfJ9OYHoWezCuZhORSGNBGU0Bya8odsG0 tT5w==
X-Gm-Message-State: AOAM532d4ti1Kz8cxEItQtdLw/LBWSQK4TD3LAvw2AS/3cyLPo2nAENn kfDAEgUw+tFmgypseBjpop5imAquseZNoZa0XB5iaixLoHk=
X-Google-Smtp-Source: ABdhPJwuNORGtfOfhfXNxMm+Dn1F8r5MzsoDyYO7buV/eNjkdCSJO/mlyCRoahOw2unp03SNXS+sCEVa5J4TVyU0VLw=
X-Received: by 2002:a92:b749:: with SMTP id c9mr7197875ilm.289.1593596520328; Wed, 01 Jul 2020 02:42:00 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: =?UTF-8?B?SmFuIFbEjWVsw6Fr?= <>
Date: Wed, 1 Jul 2020 11:41:49 +0200
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-glue-is-not-optional-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Jul 2020 09:42:04 -0000

> Abstract:
>    The DNS uses glue records to allow iterative clients to find the
>    addresses of nameservers that live within the delegated zone.  Glue
>    records are expected to be returned as part of a referral and if they
>    cannot be fitted into the UDP response, TC=1 MUST be set to inform
>    the client that the response is incomplete and that TCP SHOULD be
>    used to retrieve the full response.

Mark, thank you for writing the draft. I agree this document is needed.

It would be great if we resolved the discussion whether all existing
glue records are required or whether some number of glue records is
sufficient. I think it needs to be codified in the document.

I tend to agree with the second camp. The motivation is clear, the
resolvers need to be able to follow the delegation. However, with a
large number of NS records, I don't want to force the resolver to
retry if it already has enough information to follow the delegation.
It has been also demonstrated that resolvers are pretty bad at picking
the server with the best RTT if there are too many servers. The other
motivation is just that large responses are possible reflection attack
vectors so the DNS server operators may want to limit the number of
glue records returned.

We just opened this discussion internally at NS1 because we serve some
zones with more than 10 NS records where each NS requires glue and our
proprietary server by design adds glue only for the first four NS
records. We are discussing if this is correct behavior if it needs to
be revisited.

I also think there is another proprietary implementation of an
authoritative server in the wild which implements similar policy. It
picks a small random subset of the NS records and adds A/AAAA just for
these names. If the QNAME matches a name in the NS, A/AAAA for that NS
is always included. I find this pretty smart.

Kind regards,