[DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171

Scott Johnson <scott@spacelypackets.com> Thu, 27 June 2024 04:04 UTC

Return-Path: <scott@spacelypackets.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 B1366C14CF0C; Wed, 26 Jun 2024 21:04:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001] autolearn=ham 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 LqfAoynulMa7; Wed, 26 Jun 2024 21:04:05 -0700 (PDT)
Received: from www.spacelypackets.com (www.spacelypackets.com [IPv6:2602:fdf2:bee:feed::ee]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECF5C18DBAC; Wed, 26 Jun 2024 21:04:02 -0700 (PDT)
Received: from scott (helo=localhost) by www.spacelypackets.com with local-esmtp (Exim 4.96) (envelope-from <scott@spacelypackets.com>) id 1sMgLx-00089D-1n; Thu, 27 Jun 2024 04:03:21 +0000
Date: Thu, 27 Jun 2024 04:03:21 +0000
From: Scott Johnson <scott@spacelypackets.com>
To: Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>
In-Reply-To: <e364da36-00e3-7c14-30b0-34f20b244f0a@redbarn.org>
Message-ID: <6ff67491-30cf-cdc0-5e19-c1122465386c@spacelypackets.com>
References: <fa28794e-d02b-aa93-56c8-082a3472c6e4@spacelypackets.com> <16835c41-0e6c-bde4-d197-847928171e55@spacelypackets.com> <047a01dac6b8$43d70ca0$cb8525e0$@gmail.com> <57ca71b8-aa29-8a07-5154-e6b9c44bc64a@spacelypackets.com> <AC5B89B2-DD53-4A36-9B87-4136EC288851@isc.org> <2dec1732-841e-dd38-85a8-3263b1c59885@spacelypackets.com> <C363E260-22EA-43E9-97B6-D7A403C205ED@isc.org> <98976a58-b976-e82c-4b12-76edce92e691@spacelypackets.com> <CAMGpriUVcoJu1CWWLapwREN2NaHJFnVkGUpF45TJotm7uyAxyg@mail.gmail.com> <3cfc8b7c-9128-46b5-c458-ac0ebb9c79bc@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273735D06@tss-server1.home.tropicalstormsoftware.com> <b3ee82da-ae38-5781-77eb-bab292d5c113@spacelypackets.com> <cca98f92-27ee-d372-b419-81c63777033b@spacelypackets.com> <38A5475DE83986499AEACD2CFAFC3F980273739166@tss-server1.home.tropicalstormsoftware.com> <0910E1D8-C678-498C-BAB5-AC3AA4C75750@isc.org> <e364da36-00e3-7c14-30b0-34f20b244f0a@redbarn.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="-2112415152-364366024-1719461001=:24657"
Message-ID-Hash: 7Q3M3E3TBW7RBYZRDC2YUE75QFZGTQNI
X-Message-ID-Hash: 7Q3M3E3TBW7RBYZRDC2YUE75QFZGTQNI
X-MailFrom: scott@spacelypackets.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
CC: Rick Taylor <rick@tropicalstormsoftware.com>, Erik Kline <ek.ietf@gmail.com>, dnsop <dnsop@ietf.org>, "sburleig.sb@gmail.com" <sburleig.sb@gmail.com>, "dtn@ietf.org" <dtn@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: [dtn] Re: Re: Re: Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VQp_G13SMtyPY-FD517r_wdPJbM>
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 Paul,

Thanks for jumping in.  Comments inline.

On Wed, 26 Jun 2024, Paul Vixie wrote:

>
>
> Mark Andrews wrote on 2024-06-26 16:02:
>> 
>> 
>>> ...
>> 
>> Adding a new RRTYPE requires zero infrastructure upgrades.  It’s a 
>> database entry at IANA.  Every DNS server on the planet should handle 
>> these transparently.  That was required by RFC 1034 and RFC 1035.  You 
>> can even add them to zones before the parsing software is updated 
>> using unknown type representation (RFC 3597) which was one thing that 
>> was missing from RFC 1035 that would have made adding new types 
>> easier.  Nameservers and stub resolvers were always required to treat 
>> unknown records as opaque objects.
>
> in terms of dns infrastructure this is true. while the open source 
> implementations are fastest to adopt and deploy new rr types, even 
> proprietary dns implementations are rarely more than a year behind.
>
> but there's infrastructural middleware for which this is not true. 
> registries and registrars

If I understand your meaning, you are talking about registryfoo.com that 
sells domains and provides hosted nameservers; perhaps their web 
management interface will balk when presented with processing an unknown 
RR?

> and things like "webmin" are usually five to 
> ten years behind on adding support for new rr types.

The interesting thing about the present and near term user base of BP is 
that they generally have relationships with vendors that gives them the 
ability to complain if something they need is not supported, and get 
results. Said user base consists of, for example, space agencies, people 
who have payloads hosted on commercial CLPS landers who need to speak to 
their Lunar assets from the ground, CLPS landers themselves, commercial 
Lunar relay orbiter operators, and the like. This variable may be enough 
to encourage any such middleware vendor to enable support.


> thus, the SPF 
> debacle in which the application had to back off and go with TXT. and 
> thus the tendency today to use an existing rr type and a well-known 
> subdomain beginning with an "_" as a way to deploy more or less 
> immediately.

What can I say, I am old school, and am willing to take the risk.

>
> dns itself is not the problem. but there is a real problem here about 
> which the dns technical community can do precisely nothing.

True, but in this case it may be a small enough problem in terms of 
affected users, and the circumstances of those users, that it is 
self-resolving by existing market forces alone.

Enlightening conversation.  Thank you :)

ScottJ

>
>> This doesn’t mean that there weren’t mis-implementations of the 
>> standards which failed to handle unknown types correctly but there 
>> have been 78 types added since RFC 1034 and RFC 1035.  That’s 2-3 per 
>> year.  Nameserver developers know how to add new record types quickly.
>
> agreed, but that's not the point being argued.
>
> -- 
> P Vixie
>
> _______________________________________________
> dtn mailing list -- dtn@ietf.org
> To unsubscribe send an email to dtn-leave@ietf.org
>