[DNSOP] Re: Introducing Relative Label for DNS
Mukund Sivaraman <muks@mukund.org> Mon, 22 July 2024 12:16 UTC
Return-Path: <muks@mukund.org>
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 6D795C14CF1E for <dnsop@ietfa.amsl.com>; Mon, 22 Jul 2024 05:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=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 x9yIMEYHuPZB for <dnsop@ietfa.amsl.com>; Mon, 22 Jul 2024 05:16:36 -0700 (PDT)
Received: from mx.mukund.org (mx.mukund.org [188.40.188.216]) (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 18914C15107F for <dnsop@ietf.org>; Mon, 22 Jul 2024 05:16:34 -0700 (PDT)
Date: Mon, 22 Jul 2024 20:16:29 +0800
From: Mukund Sivaraman <muks@mukund.org>
To: Ben <ben=40yocto.com@dmarc.ietf.org>
Message-ID: <Zp5NnZJ_ooA41brT@w2>
References: <32cb827b0875605f8fbf47ccae1d4a9c@yocto.com> <690B1EDE-7DCF-4E33-9688-97295F9D842D@gmail.com> <0dc78e99117e369d6d617b937495d722@yocto.com> <Zp4kK5Ad39SLkJo2@w2> <0c4b573f7173761dc35df5eae101d7c8@yocto.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="7ZrRecIu1fPdrEVC"
Content-Disposition: inline
In-Reply-To: <0c4b573f7173761dc35df5eae101d7c8@yocto.com>
Message-ID-Hash: NEYPRZUNKNJEWFIXSVMX5UDLLNS7YLVS
X-Message-ID-Hash: NEYPRZUNKNJEWFIXSVMX5UDLLNS7YLVS
X-MailFrom: muks@mukund.org
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
CC: dnsop@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Introducing Relative Label for DNS
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CbIJTF0z8yweMQqvOJ8KPXbJEag>
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>
Hi Ben On Mon, Jul 22, 2024 at 09:40:02AM +0000, Ben wrote: > > > I think we should not focus to much specificly on how BIND handles > > > things > > > with $ORIGIN. I'm talking about the concept of zones in general. For > > > > $ORIGIN is from RFC 1035, for any implementation that supports master > > files. It is not a BIND-specific item. > I thought it was BIND-specific, but because everybody loved that zone > format, it got standardized by a section in RFC 1035. A lot of things in the DNS can be thought as BIND-specific if it were documented after implementation in BIND. :) Your initial comment was "we should not focus too much specificly on how BIND handles things with $ORIGIN"; it is how implementations that parse master files handle $ORIGIN. It is not BIND-specific. I tried to look up when $ORIGIN got introduced in BIND. :) On ftp.isc.org, I could find versions starting from 4.8, but that was newer than 1987 when RFC 1035 was published. So I tried finding it in 4.3BSD source code trees; the only one I could find predating 1987 (if the sccsid can be believed) is here: https://www.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/etc/bind/named/db_load.c which implemented $ORIGIN. (We on this list are fortunate to have Paul Vixie on it and he may be able to offer more history.) Some older docs on BIND: https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/CSD-84-182.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/1984/CSD-84-177.pdf That Berkeley tech reports archive is a treasure trove. All sorts of cool things came from there. Mukund
- [DNSOP] Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Alexander Robohm
- [DNSOP] Re: Introducing Relative Label for DNS Ben
- [DNSOP] Re: Introducing Relative Label for DNS Ben
- [DNSOP] Re: Introducing Relative Label for DNS Mukund Sivaraman
- [DNSOP] Re: Introducing Relative Label for DNS Mukund Sivaraman
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Alexander Robohm
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Edward Lewis
- [DNSOP] Re: Introducing Relative Label for DNS Joe Abley
- [DNSOP] Re: Introducing Relative Label for DNS Ondřej Surý
- [DNSOP] Re: Introducing Relative Label for DNS Tim Wicinski
- [DNSOP] Re: Introducing Relative Label for DNS Ben
- [DNSOP] Re: Introducing Relative Label for DNS Peter Thomassen
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Mark Andrews
- [DNSOP] Re: Introducing Relative Label for DNS Peter Thomassen
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Q Misell
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt