Re: [DNSOP] NSA says don't use public DNS or DoH servers

> On Jan 21, 2021, at 8:59 PM, Paul Vixie wrote: > > On Thu, Jan 21, 2021 at 03:36:41PM -0800, Wes Hardaker wrote: >> "John Levine" writes: >> >>> They think DoH is swell, but not when it bypasses security controls >>> and leaks info to random outside people >> >> At least 15% of network

Re: [DNSOP] Authoritative servers announcing capabilities

> On Sep 19, 2020, at 5:51 AM, Ray Bellis wrote: > >  > >> On 14/09/2020 15:32, libor.peltan wrote: >> Let me leave some personal opnion/comments on this AUTHINFO idea, although I >> don't know the background here. >> There are multiple kinds of "capabilities" of an authoritative server. >>

[DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-04.txt

egin forwarded message: > From: internet-dra...@ietf.org > Date: November 4, 2019 at 11:27:25 AM EST > To: Tim Wattenberg , Tom Pusateri > Subject: New Version Notification for > draft-pusateri-dnsop-update-timeout-04.txt > >  > A new version of I-D, draft-pusateri-dnsop

[DNSOP] TIMEOUT resource record RDATA format revisited

DNSOP, It’s exciting to see some implementation experience in bind 9 by Mark Andrews for TIMEOUT records and during this process several issues have come up with the current use of RDATA as the method to match represented records. Thanks Mark for all the work and feedback so far! 1.

Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

> On Mar 8, 2019, at 3:00 PM, 神明達哉 wrote: > > At Mon, 4 Mar 2019 19:45:02 -0500, > Tom Pusateri mailto:pusat...@bangj.com>> wrote: > > > Thanks to the great feedback, we were able to update the document to > > better match the preferences of the working grou

Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

> On Mar 5, 2019, at 8:20 AM, Tony Finch wrote: > > Tom Pusateri wrote: >> >> Sorry if that freaked you out. > > I wasn't freaked out, I just thought the response was directed to the > wrong place. I didn't bring up the issue for a two-way discussion, I

Re: [DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

> On Mar 5, 2019, at 7:18 AM, Tony Finch wrote: > > Tom Pusateri wrote: >> >> Modify presentation format of date/time to match RRSIG (Mark Andrews) > > I got some mail from github about this issue which was weirdly sent to > me personally rather than to the WG

[DNSOP] draft-pusateri-dnsop-update-timeout-02.txt

> From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-pusateri-dnsop-update-timeout-02.txt > Date: March 4, 2019 at 7:26:58 PM EST > To: "Tim Wattenberg" , "Tom Pusateri" > > > > A new version of I-D, draft-pusateri-dnsop-up

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

> On Feb 21, 2019, at 10:19 PM, Tom Pusateri wrote: > > > >> On Feb 21, 2019, at 1:29 PM, Ted Lemon > <mailto:mel...@fugue.com>> wrote: >> >> On Feb 21, 2019, at 2:24 PM, Mark Andrews > <mailto:ma...@isc.org>> wrote: >>> Imp

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

> On Feb 21, 2019, at 1:29 PM, Ted Lemon wrote: > > On Feb 21, 2019, at 2:24 PM, Mark Andrews > wrote: >> Implementation details are beyond the scope of RFCs. > > Indeed they are. My point is that if you want to be careful of memory usage > or disk usage, you can

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

ding a shim layer. It’s checking for the existence on all the platforms > the server is built on. > > https://github.com/pusateri/draft-pusateri-dnsop-update-timeout/issues/19 > >> On 19 Feb 2019, at 10:34 am, Tom Pusateri wrote: >> >> DNSOP, >> >> We have upd

[DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-01.txt

& Tim > Begin forwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-pusateri-dnsop-update-timeout-01.txt > Date: February 18, 2019 at 6:26:35 PM EST > To: "Tim Wattenberg" , "Tom Pusateri" > &g

[DNSOP] DNS JSON (RFC 8427) schema

DNSOP/Paul: I am working on an application that will have DNS filters or translators in the config file. My current design uses Paul Hoffman's RFC 8427 JSON DNS format to allow the filters to make packet alterations. As an example, think about an older printer service with SRV/TXT

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Sep 3, 2018, at 8:58 PM, Mark Andrews wrote: > > SHAKE128 does not meet these requirements. In OPENSSL it is only > available in pre-release code. It will be years before OPENSSL-1.1.1 > is the OPENSSL release for most operating systems. > > We (ISC) haven’t started working out what

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

rvice. So there shouldn’t be > a problem. > > On Mon, Aug 27, 2018 at 2:28 PM Tom Pusateri <mailto:pusat...@bangj.com>> wrote: > Because even if you add TYPE, you have multiple PTR records (instance names) > with the same owner name, class, and type that can timeout differentl

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 27, 2018, at 2:25 PM, Tom Pusateri wrote: > > > Sorting the timeouts is a good idea. > Well, maybe sorting timeouts is a good idea. Depending on how they are represented internally, it makes no difference. I would like to hear from implementors whether this even m

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Because even if you add TYPE, you have multiple PTR records (instance names) with the same owner name, class, and type that can timeout differently. Tom > On Aug 26, 2018, at 11:20 PM, Ted Lemon wrote: > > If we do that, why do we need a hash at all? > > On Sun, Aug 26, 2018 at 10:51 PM Mark

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 26, 2018, at 10:51 PM, Mark Andrews wrote: > > I would add a covered type field to TIMEOUT (c.f. RRSIG). I also wouldn’t > have more than > a single timeout per record. I’m tempted to say a single hash as well. If > there is multiple > timeouts per record then the blocks need to

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

ck around for a while so that the name can't > be claimed by a rogue service just because e.g. the printer is powered off > right now. > >> On Aug 26, 2018, at 10:22 PM, Tom Pusateri wrote: >> >> >>> On Aug 26, 2018, at 8:12 PM, Ted Lemon wrote: >>&g

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

By the way, the SRP case looks messy because SRP chooses to have different lease lifetimes for KEY records. If the lease lifetimes were all the same, as I would expect for most UPDATES, everything would be simpler. Tom > On Aug 26, 2018, at 10:22 PM, Tom Pusateri wrote: > > >

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 26, 2018, at 8:12 PM, Ted Lemon wrote: > > The timeout isn't the same for DNSSD Registration Protocol. Ok, this is a little detailed but let's take what the current draft says and be explicit about your particular SRP case. I think I am representing SRP correctly but if not, please

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 26, 2018, at 7:07 PM, Paul Vixie wrote: > > Tom Pusateri wrote: >> >> There’s no attack vector here. And a collision would have to be >> another valid RR already in the database with the same owner name and >> class. This is literally impossible. Prob

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 26, 2018, at 6:54 PM, Paul Vixie wrote: > > > > Tom Pusateri wrote: > ... >> SHAKE128 as well as other SHA-3 algorithms have been found to be >> quitecollision resistant. > > right. they all are, at first. we're building for our grandkids

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 26, 2018, at 3:59 PM, Paul Vixie wrote: > >> On Sunday, August 26, 2018 5:47:43 PM UTC Tom Pusateri wrote: >> ... >> Nice properties of the hash: >> >> 1. the length of the output value is consistent across varying input lengths >

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

I actually think the hash won’t be needed as much as you think. If the timeout is the same, even though the record types are different, you still don’t need the hash. Is this straightforward? // // main.c // requires OpenSSL 1.1.1 or later // // Created by Tom Pusateri on 8/26/18

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 26, 2018, at 1:47 PM, Tom Pusateri wrote: > > > >> On Aug 26, 2018, at 12:58 PM, Ted Lemon > <mailto:mel...@fugue.com>> wrote: >> >> On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri > <mailto:pusat...@bangj.com>> wrote: >>

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 26, 2018, at 12:58 PM, Ted Lemon wrote: > > On Sat, Aug 25, 2018 at 3:09 PM Tom Pusateri <mailto:pusat...@bangj.com>> wrote: > I think I already agreed with you here. > > My main point was that the primary needs a database and it already has one > and

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

on? Why is it a problem > if the garbage collection is delayed? If the primary is down, it's not like > some other device could claim that name anyway. > > On Sat, Aug 25, 2018 at 2:11 PM Tom Pusateri <mailto:pusat...@bangj.com>> wrote: > This is a valid question. >

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 25, 2018, at 2:53 PM, Paul Vixie wrote: > > On Saturday, August 25, 2018 6:11:48 PM UTC Tom Pusateri wrote: >> ... >> >> In most cases, having the primary remember the lease lifetime should be >> enough. But if the outage is longer than the l

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

es have such authority so don’t discount DHCP >> derived addresses. >> >> -- >> Mark Andrews >> >> On 25 Aug 2018, at 12:53, Ted Lemon > <mailto:mel...@fugue.com>> wrote: >> >>> When would that happen? >>> >>> On

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

gt; > -- > Mark Andrews > > On 25 Aug 2018, at 05:02, Tom Pusateri <mailto:pusat...@bangj.com>> wrote: > >> >> >>> On Aug 24, 2018, at 2:59 PM, Ted Lemon >> <mailto:mel...@fugue.com>> wrote: >>> >>> On Au

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 24, 2018, at 3:46 AM, Mark Andrews wrote: > > This is unnecessary. All the rule does is limit the process to class IN > zones. UPDATE, IXFR and AXFR are class agnostic. > > 1. TIMEOUT resource records are only defined for CLASS IN. Ok, we will make them applicable to all

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 24, 2018, at 2:59 PM, Ted Lemon wrote: > > On Aug 24, 2018, at 2:43 PM, Tom Pusateri <mailto:pusat...@bangj.com>> wrote: >> It seems odd to take the position that the authoritative server shouldn’t >> need to clean up stale entries because

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Sorry, I never surveyed the set of inconsiderate DCHP servers. Thanks, Tom > On Aug 24, 2018, at 2:04 PM, Ted Lemon wrote: > > Can you give us an example? > >> On Fri, Aug 24, 2018 at 1:56 PM Tom Pusateri wrote: >> Sure. It’s not the thoughtful, well-behaved imple

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

P servers automatically > remove these records. The ISC server has been doing this for 20 years, and > I'm pretty sure all the other servers that compete with it do too. > > On Fri, Aug 24, 2018 at 12:50 PM, Tom Pusateri <mailto:pusat...@bangj.com>> wrote: > > >&

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 24, 2018, at 9:54 AM, Ted Lemon wrote: > > On Aug 24, 2018, at 9:52 AM, Tom Pusateri <mailto:pusat...@bangj.com>> wrote: >> Yes, it was intended to be more general than for service registration. It’s >> directly applicable to name registrati

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 24, 2018, at 10:11 AM, Joe Abley wrote: > > Hi Tom, > >> On Aug 24, 2018, at 09:52, Tom Pusateri wrote: >> >>> If a zone is signed, are the TIMEOUT records signed? >> >> No. The draft says they are skipped. > > New RRTypes are su

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

> On Aug 24, 2018, at 9:11 AM, Ted Lemon wrote: > > On Aug 23, 2018, at 11:44 PM, Tom Pusateri wrote: >> An RRset isn’t granular enough because the components of the set could come >> from different clients with different timeout values. >> Therefore, a unique id

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

I don’t think there is a TTL issue because, as we proposed it, the record is never returned in a query. The TTL could always be set to 0 for our purposes since it never leaves the authoritative servers. Tom > On Aug 23, 2018, at 11:44 PM, Tom Pusateri wrote: > > Paul, &g

Re: [DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

Paul, Thanks for the feedback! An RRset isn’t granular enough because the components of the set could come from different clients with different timeout values. Therefore, a unique identifier is needed for each record. The hash provides that unique identifier since it is calculated over the

[DNSOP] Fwd: New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

rwarded message: > > From: internet-dra...@ietf.org > Subject: New Version Notification for > draft-pusateri-dnsop-update-timeout-00.txt > Date: August 23, 2018 at 8:47:39 PM EDT > To: "Tim Wattenberg" , "Tom Pusateri" > > > > A new version of I

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 21, 2018, at 3:30 PM, Paul Vixie wrote: > > this, joyfully, is a very good question. > > Tom Pusateri wrote: > >> Ok, so as Vladimír said, getting back to DHCP… >> >> 1. You obviously don’t need a DoH URI option for DHCP. 2. You’re >>

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 21, 2018, at 2:54 PM, Paul Vixie wrote: > > > > David Conrad wrote: >> Vittorio, >> >> ... >> >> Perhaps I’m misunderstanding: are you saying the folks who provide >> resolution services in a DoH world would have incentive to not follow >> basic security measures? > > noting that

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 21, 2018, at 7:33 AM, Tony Finch wrote: > > Tom Pusateri wrote: > >> Come to think of it, DNSSEC validation in the stub resolver or browser >> is really a place DoH could shine. Instead of all the round trips >> required for validating up (

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 21, 2018, at 3:30 AM, Marek Vavruša > wrote: > > On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček <mailto:petr.spa...@nic.cz>> wrote: >> On 21.8.2018 04:38, Tom Pusateri wrote: >>> Come to think of it, DNSSEC validation in the stub resolver or bro

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

the validation quickly for all of the links in a page in an order that the user is most likely to need based on previous statistics and scrolling position. Tom > On Aug 20, 2018, at 10:31 PM, Tom Pusateri wrote: > > Sure. My point was that there could be legitimate uses of DoH. > > Y

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

n is, how does the consumer of that data decide what is > okay and what's not? We can't just say that the server has to behave > correctly: someone has to enforce it. > > On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri <mailto:pusat...@bangj.com>> wrote: > > &g

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 20, 2018, at 10:21 PM, Paul Vixie wrote: > > > > Tom Pusateri wrote: >> ... I don’t know if it’s generally accepted that DoH will replace >> UDP/53 or DoT in the stub resolver or DoH will just end up in the >> browsers as a way to spe

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 20, 2018, at 9:40 PM, Paul Ebersman wrote: > > pusateri> Another point I remember most clearly is that DHCP has fallen > pusateri> out of favor for communicating all but the most minimal > pusateri> network bootstrap configuration information. There was general > pusateri> agreement

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 20, 2018, at 12:42 PM, Tony Finch wrote: > > Marek Vavruša wrote: >> >> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive..txt > > This is interesting to me because I want to support DoTH on my campus > resolvers. > > Regarding DoH, the DHCP option ought

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

> On Aug 19, 2018, at 9:29 AM, Livingood, Jason > wrote: > > On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" on behalf of bert.hub...@powerdns.com> wrote: >Especially when such a move will incidentally kill intranets, VPNs, split >horizon, DNS monitoring & DNS malware detecion

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

authentication for the purpose of doing >> Reconfigure; this authentication is not sufficient to provide assurances of >> trustworthiness. It's about as secure as a TCP sequence number. >> >>> >>> I'm happy if we say the draft must depend on RFC3315, or discuss the &

Re: [DNSOP] Moving forward with DNS Stateful Operations

> On Aug 2, 2018, at 11:32 AM, Ted Lemon wrote: > > We got some really good review during the IESG last call process. Thanks to > the IESG members (bcc) who read the document thoroughly and gave so many > thoughtful comments. > > I believe that we have addressed all of the comments that

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

Ted, Those clarifications look good. Thanks, Tom > On Aug 2, 2018, at 10:53 AM, Ted Lemon wrote: > > On Thu, Aug 2, 2018 at 9:54 AM, Benjamin Kaduk > wrote: > > We specifically didn’t want to reference DoH since HTTP is unsuitable for > > long lived connections

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

> On Jul 31, 2018, at 3:53 PM, Tom Pusateri wrote: > >> >> If the RCODE is set to any value other than NOERROR (0) or DSOTYPENI >> ([TBA2] tentatively 11), then the client MUST assume that the server >> does not implement DSO at all. In thi

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-session-signal-12: (with DISCUSS and COMMENT)

> On Jul 27, 2018, at 11:24 AM, Benjamin Kaduk wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dnsop-session-signal-12: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines.

Re: [DNSOP] SIG(0) useful (and used?)

> On Jun 21, 2018, at 1:40 PM, Shumon Huque wrote: > > On Thu, Jun 21, 2018 at 8:05 AM Tom Pusateri <mailto:pusat...@bangj.com>> wrote: >> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát > <mailto:vladimir.cunat+i...@nic.cz>> wrote: >> >> On 06/

Re: [DNSOP] SIG(0) useful (and used?)

> On Jun 21, 2018, at 12:19 AM, Vladimír Čunát > wrote: > > On 06/20/2018 04:59 PM, Tom Pusateri wrote: >> DNSSEC will tell you the answer you get is correct but it could be a > to a >> different question or be incomplete. > Can you elaborate on that point.

Re: [DNSOP] SIG(0) useful (and used?)

> On Jun 20, 2018, at 3:23 PM, Shane Kerr wrote: > > Ondřej, > > Ondřej Surý: >> as far as I could find on the Internet there are only SIG(0) implementation >> in handful DNS implementations - BIND, PHP Net_DNS2 PHP library, >> Net::DNS(::Sec) Perl library, trust_dns written in Rust and

Re: [DNSOP] SIG(0) useful (and used?)

> On Jun 19, 2018, at 4:48 PM, Ondřej Surý wrote: > > > Do people think the SIG(0) is something that we should keep in DNS and it > will be used in the future or it is a good candidate for throwing off the > boat? > > Ondrej As far as I can tell, SIG(0) is the only mechanism in DNS to

Re: [DNSOP] Fwd: Last Call: (DNS Stateful Operations) to Proposed Standard

> On Jun 12, 2018, at 10:28 AM, Job Snijders wrote: > > Dear Ted, > > On Tue, Jun 12, 2018 at 3:09 PM, Ted Lemon wrote: >> Yes. I'm using it right now to implement draft-ietf-dnssd-mdns-relay, and >> that implementation is working and interoperating. I don't know of another >>

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-10.txt

> On Jun 7, 2018, at 1:56 PM, Bob Harold wrote: > > > On Thu, Jun 7, 2018 at 1:43 PM Tom Pusateri <mailto:pusat...@bangj.com>> wrote: > This updated version adds some minor changes requested by Warren including > anycast clarifcation, a new RFC reference,

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-10.txt

Sara Dickinson > Ted Lemon > Tom Pusateri > Filename: draft-ietf-dnsop-session-signal-10.txt > Pages : 53 > Date: 2018-06-07 > > Abstract: > This d

Re: [DNSOP] AD review of draft-ietf-dnsop-session-signal

I made all of these suggested changes on github except for the Section 3 “same server instance” pandora’s box. The authors can discuss how they want to change this one or leave it for later. If I don’t hear anything in a day or two, I’ll push out another version. Thanks, Tom > On Jun 2,

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-08.txt

DNS Stateful Operations >Authors : Ray Bellis > Stuart Cheshire > John Dickinson > Sara Dickinson > Ted Lemon > Tom Pusateri > Filename

Re: [DNSOP] Complexity and innovation in the DNS protocol: the work of DNSOP

> On Apr 18, 2018, at 5:07 PM, Suzanne Woolf wrote: > > Hi, > > The chairs have been discussing next steps after IETF 101, particularly the > very lively WG input on the complexity and stability of the DNS protocol. > > There are many aspects to the questions that

Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt

> On Aug 18, 2017, at 11:12 AM, Petr Špaček wrote: > > We can certainly call TLVs "extension" but renaming it does not remove > the fundamental problem: > TLVs are largely incompatible with the code we already have widely > implemented and deployed everywhere in all the DNS