IETF Logo Mail Archive

Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient...

Joe Abley <jabley@hopcount.ca> Fri, 22 May 2020 14:52 UTC

Return-Path: <jabley@hopcount.ca>
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 CBA0A3A0A84 for <dnsop@ietfa.amsl.com>; Fri, 22 May 2020 07:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 DC3PLUOwg_Hx for <dnsop@ietfa.amsl.com>; Fri, 22 May 2020 07:52:32 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 B451E3A0A36 for <dnsop@ietf.org>; Fri, 22 May 2020 07:52:32 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id f83so10860108qke.13 for <dnsop@ietf.org>; Fri, 22 May 2020 07:52:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BhtmnAS2kwG2Q1Neu+izGzj9ujex9ssniKKG2y71rXo=; b=mme+6n6MASISvQpfYc4GFOVCElEYpeihFuIg2vu4tgwiXA2DG6ZnvXUSqP9bzx4DY8 hW1oV7UHpcKPJ7ngQRIUDb71G/ppBMqPgQ+isTujpcfpU536SkvmpBjUGq/5i4aSXVDY VSqjoynSC49WNJyqyRWyJ5OOgEXhdW/oZ5oAU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BhtmnAS2kwG2Q1Neu+izGzj9ujex9ssniKKG2y71rXo=; b=QiTBB60yKtGKzuNwwQpzUoNmspBh8ghrxpwA7DvrCJYPsOAUfAQ3wR7G68lKF32XZ6 +3UBUlMRQaJNx+hAQlHuqz6a3gDmdyM+PBleWzbyT3ICrD20jmzdznRausZP2o6nYvSU by2ovt2q/fSIC3rD4OZUDklr9UhDtdwu6FxjuZxqyfV1qPENFoFq62l4g0DLmK5GBEVi EHTAh1hCpLNIa5zXb55gL7FTP2GnVH9H7EOFRtVMgtvy1d98VsuItD1+hN0XpuhY3JgY mcB3omUqrvAAbkHuvneSjXdonL4z6wlXSkR6HABTvUeo+9hvr/YJ4WB5K6Rf5b9N3SmB YOog==
X-Gm-Message-State: AOAM530b8q5fwAIc9Y780YGttADpGHoYd5f25EtNujLmXAyPGNPPUNmo kW/ocn9FI5YyqYl3ksIQvh64oZ5LR2JV1QIj
X-Google-Smtp-Source: ABdhPJy1waX6ywJCCzNXyrMJQerd9at9jfGqEeMYtx8DlLmeyxIq+apZbI7r5YVgp4OcmPuOPHpgIg==
X-Received: by 2002:a37:bd82:: with SMTP id n124mr15623867qkf.168.1590159150574; Fri, 22 May 2020 07:52:30 -0700 (PDT)
Received: from ?IPv6:2607:f2c0:e784:c7:dc08:d905:3ae2:aab9? ([2607:f2c0:e784:c7:dc08:d905:3ae2:aab9]) by smtp.gmail.com with ESMTPSA id g1sm7999121qkm.123.2020.05.22.07.52.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 May 2020 07:52:29 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <CAHw9_i+UsV9NkuPM4KYBZhO7_J78MkUEyVR3fr=vOX-vsjJeUA@mail.gmail.com>
Date: Fri, 22 May 2020 10:52:28 -0400
Cc: dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDBED5AB-54D8-4936-8509-802472FA3B11@hopcount.ca>
References: <CAHw9_i+UsV9NkuPM4KYBZhO7_J78MkUEyVR3fr=vOX-vsjJeUA@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NTFj6alIvi1__QrMQCY2A3e0Urw>
Subject: Re: [DNSOP] Glue is not optional, but sometimes it *is* sufficient...
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: Fri, 22 May 2020 14:52:34 -0000

On 21 May 2020, at 16:07, Warren Kumari <warren@kumari.net> wrote:

> What does all of this *mean*?
> ..
> ..
> ..
> Sorry, I haven't a clue, other than maybe:
> The DNS is weird.

In your experiment it seems clear that all the glue records you are looking for are being returned from the involved authority-only servers in the additional section, and since for the COM zone that's a well-constrained monoculture of software it seems reasonable to imagine that's not where to look.

Similarly, by testing using Atlas probes the stub resolver presumably also represents a monoculture (or if there are different versions of probes, there are surely not that many different versions).

What remains is the tangle of resolvers, forwarders and proxies that exist between RIPE atlas probes and the authority servers, where there might actually be dragons. Not for the first time, I wish we had something like traceroute in the DNS so that we could isolate those paths rather than simply looking at exit addresses and trying to make inferences from them. I guess for some (apparently decreasing) proportion of those Atlas probes there's at least one dragon between the probe and the COM server that caches additional section glue and is happy to return it as an answer. I don't have any clever ideas about how you'd isolate any particular fictional reptile, however.

It'd be interesting to continue this kind of experiment over time and see where the success rate for those queries is trending.


Joe

v2.23.0 | Report a Bug | By Email