[DNSOP] Re: [EXTERNAL] New Version Notification for draft-jens-7050-secure-channel-00.txt

[Tommy Jensen]

Hello dnsop and v6ops,

I've written a draft that proposes updates to RFC 7050, which defined the 
mechanism for discovering the network's IPv6 translation prefix using a DNS 
query for ipv4only.arpa. RFC 7050 also defined "secure channel" such that 
clients SHOULD use IPsec or similar to secure communications with the DNS64 
server.

However, since 7050 was published, various encrypted DNS protocols combined 
with DNR (RFC 9463) allows DNS64 servers to have their encrypted DNS config 
directly advertised by the network and nodes can then use DoT, DoH, or DoQ to 
securely communicate with the DNS64 server. This text updates 7050 to recommend 
that approach, along with discouraging use of the previously defined DNSSEC 
mechanism (since the name of the resolver is now known and can be confirmed 
using TLS).

Given the behave WG has disbanded, Warren recommended I approach dnsop for 
initial discussion and include v6ops for discussion (for v6ops context: this is 
part of the secondary work that came out of the draft Jen and I are writing for 
CLAT Best Practices). I am seeking feedback on whether updating 7050 is the 
correct approach, and more generally, if there's interest in taking up work in 
the area of "revisiting how a stub resolver should secure its communication 
with a DNS64 resolver".

Thanks,
Tommy

P.S. I noticed I ended up with the 2119 section at the bottom... oh well, next 
time.


From: internet-dra...@ietf.org 
Sent: Tuesday, June 25, 2024 10:37 PM
To: Tommy Jensen
Subject: [EXTERNAL] New Version Notification for 
draft-jens-7050-secure-channel-00.txt

A new version of Internet-Draft draft-jens-7050-secure-channel-00.txt has been
successfully submitted by Tommy Jensen and posted to the
IETF repository.

Name: draft-jens-7050-secure-channel
Revision: 00
Title:Redefining Secure Channel for ipv4only.arpa IPv6 Prefix Discovery
Date: 2024-06-26
Group:Individual Submission
Pages:11
URL:  https://www.ietf.org/archive/id/draft-jens-7050-secure-channel-00.txt
Status:   https://datatracker.ietf.org/doc/draft-jens-7050-secure-channel/
HTML: https://www.ietf.org/archive/id/draft-jens-7050-secure-channel-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-jens-7050-secure-channel


Abstract:

   This document updates [RFC7050] to redefine the term "secure channel"
   and modify requirements for nodes and DNS64 servers to use more
   recent developments in DNS security.



The IETF Secretariat


___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [v6ops] Re: [EXTERNAL] New Version Notification for draft-jens-7050-secure-channel-00.txt

[Tommy Jensen]

That's a fun question. I took this approach based on my operating assumption 
that 7050 is still useful to some folks (noting 7050 is also still in the CLAT 
recommendations draft Jen and I are writing). I wouldn't be opposed to writing 
a deprecation instead if consensus indicates 7050 is no longer needed.

One use case could be 8781 is harder for apps above the networking stack to 
read, which applies to NAT64+DNS64 in the absence of 464XLAT and apps that are 
IPv6 aware trying to reach IPv4 only destinations. I might be tossing a match 
into fuel here, but to answer your question, I think we need to first answer 
"what is our recommended story for IPv6-aware apps communicating with IPv4-only 
peers when the OS gives it no IPv4 address or CLAT?"

There may be other use cases for 7050 that 8781 can't meet, but I'll let others 
speak up if they want for those. I certainly have a PREFerence for 8781.

Thanks,
Tommy

From: Brian Candler 
Sent: Wednesday, June 26, 2024 12:21 AM
To: Tommy Jensen ; dnsop@ietf.org 
Cc: V6 Ops List 
Subject: Re: [v6ops] Re: [EXTERNAL] New Version Notification for 
draft-jens-7050-secure-channel-00.txt

On 26/06/2024 06:50, Tommy Jensen wrote:
> I am seeking feedback on whether updating 7050 is the correct
> approach, and more generally, if there's interest in taking up work in
> the area of "revisiting how a stub resolver should secure its
> communication with a DNS64 resolver".

With the PREF64 mechanism (RFC8781) already seeing widespread adoption,
are we at a point where we could simply deprecate RFC7050?

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Tommy Jensen]

Hello dnsop,

Not to distract from the "should we deprecate DNS64" discussion I started after 
proposing updates to 7050, but this is the second draft (last one, I promise) 
I'll be proposing to this group as interesting work ahead of IETF 120. Joining 
me are co-authors Jessica from Microsoft and Jeff and Matt from Amazon.

In light of enterprises increasingly using encrypted DNS for their own 
"Protective DNS" resolvers, we are proposing best practices for when and how to 
use client authentication with encrypted DNS. Since this is a Good Thing for 
enterprises who control both peers (stronger security for client policy 
application and security auditing post-attack) and a Bad Thing otherwise 
(privacy violations for the non-enterprises cases common to consumers), we feel 
there is a need to specify when implementors should or should not use it.

Spoiler alert: we prefer mTLS as the ideal authentication mechanism. I'll let 
the draft speak for itself as to why. Feedback and discussion is welcome.

Thanks,
Tommy


From: internet-dra...@ietf.org 
Sent: Thursday, June 27, 2024 11:32 AM
To: Jeffrey Damick ; Jessica Krynitsky 
; Matt Engskow ; Tommy 
Jensen 
Subject: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

A new version of Internet-Draft draft-tjjk-cared-00.txt has been successfully
submitted by Tommy Jensen and posted to the
IETF repository.

Name: draft-tjjk-cared
Revision: 00
Title:Client Authentication Recommendations for Encrypted DNS
Date: 2024-06-27
Group:Individual Submission
Pages:11
URL:  https://www.ietf.org/archive/id/draft-tjjk-cared-00.txt
Status:   https://datatracker.ietf.org/doc/draft-tjjk-cared/
HTML: https://www.ietf.org/archive/id/draft-tjjk-cared-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-tjjk-cared


Abstract:

   For privacy reasons, encrypted DNS clients need to be anonymous to
   their encrypted DNS servers to prevent third parties from correlating
   client DNS queries with other data for surveillance or data mining
   purposes.  However, there are cases where the client and server have
   a pre-existing relationship and each peer wants to prove its identity
   to the other.  For example, an encrypted DNS server may only wish to
   accept resolutions from encrypted DNS clients that are managed by the
   same enterprise.  This requires mutual authentication.

   This document defines when using client authentication with encrypted
   DNS is appropriate, the benefits and limitations of doing so, and the
   recommended authentication mechanism(s) when communicating with TLS-
   based encrypted DNS protocols.



The IETF Secretariat


___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

[Tommy Jensen]

Hey Ben,

Thank you for reading the draft and your comments.

I agree we would not need a draft for saying mTLS works as expected. This draft 
is saying something different: "mTLS is the way one should auth clients to 
encrypted DNS servers for many reasons, cross-protocol use among them." The 
cost of doing something like "make OAuth or Privacy Pass work with DoT and DoQ" 
needs to be weighed against what benefits that would give over using mTLS that 
matter to the narrow use case where using client auth with encrypted DNS is 
appropriate (where both client and server are managed by the same authority, 
such as enterprise end-to-end).

For example, you talk about "privacy properties" of PrivacyPass — which 
properties are you thinking about that would apply to the enterprise use case 
and be more useful than mTLS as a result? That's not a leading question, I 
legitimately don't know enough about PrivacyPass to know. Conversely, can you 
expand on the downsides of mTLS versus OAuth or PrivacyPass? If you would like 
to see a different recommendation, it would be good to understand why. If you 
disagree with the requirements the draft defined to based its reasoning on, 
that's a good place to start too (I note the markdown didn't survive the 
submission and the bulleted lists in the first two paragraphs of section 6 are 
not lists, sorry about that).

Thanks,
Tommy


From: Ben Schwartz 
Sent: Monday, July 22, 2024 4:18 PM
To: Tommy Jensen ; dnsop 
Cc: Damick, Jeffrey ; Jessica Krynitsky 
; Engskow, Matt 
Subject: Re: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

mTLS might be the most pragmatic approach today in many situations, but I don't 
think we can recommend it in the way that this draft would.  It has some 
significant downsides, especially when compared against something like OAuth 
(which might integrate better with user account systems) or Privacy Pass* 
(which has much better privacy properties).  It's true that these mechanisms 
can't be used with DoT and DoQ today, but it is within our power to fix that if 
we care to.

If the only significance of this draft is today "mTLS works as you would expect 
for DoT, DoQ, and DoH", then I don't think we need a draft to tell us that.

--Ben

*I am a co-chair of PRIVACYPASS but I am speaking only as an individual 
participant..

From: Tommy Jensen 
Sent: Thursday, June 27, 2024 2:41 PM
To: dnsop 
Cc: Damick, Jeffrey ; Jessica Krynitsky 
; Engskow, Matt 
Subject: [DNSOP] Re: [EXTERNAL] New Version Notification for 
draft-tjjk-cared-00.txt

Hello dnsop,

Not to distract from the "should we deprecate DNS64" discussion I started after 
proposing updates to 7050, but this is the second draft (last one, I promise) 
I'll be proposing to this group as interesting work ahead of IETF 120. Joining 
me are co-authors Jessica from Microsoft and Jeff and Matt from Amazon.

In light of enterprises increasingly using encrypted DNS for their own 
"Protective DNS" resolvers, we are proposing best practices for when and how to 
use client authentication with encrypted DNS. Since this is a Good Thing for 
enterprises who control both peers (stronger security for client policy 
application and security auditing post-attack) and a Bad Thing otherwise 
(privacy violations for the non-enterprises cases common to consumers), we feel 
there is a need to specify when implementors should or should not use it.

Spoiler alert: we prefer mTLS as the ideal authentication mechanism. I'll let 
the draft speak for itself as to why. Feedback and discussion is welcome.

Thanks,
Tommy


From: internet-dra...@ietf.org 
Sent: Thursday, June 27, 2024 11:32 AM
To: Jeffrey Damick ; Jessica Krynitsky 
; Matt Engskow ; Tommy 
Jensen 
Subject: [EXTERNAL] New Version Notification for draft-tjjk-cared-00.txt

A new version of Internet-Draft draft-tjjk-cared-00.txt has been successfully
submitted by Tommy Jensen and posted to the
IETF repository.

Name: draft-tjjk-cared
Revision: 00
Title:Client Authentication Recommendations for Encrypted DNS
Date: 2024-06-27
Group:Individual Submission
Pages:11
URL:  
https://www.ietf.org/archive/id/draft-tjjk-cared-00.txt<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-tjjk-cared-00.txt__;!!Bt8RZUm9aw!_8-BG_G6wHMcs_UVkwXqP0aVV9tQKSxtFZUsEClBxt2Mdmibw_KPRkiy1Bwe1ic3RrtchGlsJQRm-doecb78MhYiKeo$>
Status:   
https://datatracker.ietf.org/doc/draft-tjjk-cared/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-tjjk-cared/__;!!Bt8RZUm9aw!_8-BG_G6wHMcs_UVkwXqP0aVV9tQKSxtFZUsEClBxt2Mdmibw_KPRkiy1Bwe1ic3RrtchGlsJQRm-doecb78334FWQc$>
HTML: 
https://www.ietf.org/archive/id/draft-tjjk-cared-00.html<https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-tjjk-cared-00.html_

Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

[Tommy Jensen]

The link you shared indicates the problem is RC4, which was removed from TLS in 
1.3 for this very reason. This doesn’t demonstrate TLS 1.3 is vulnerable; it 
demonstrates why adopting TLS 1.3 is so important.

Thanks,
Tommy

From: DNSOP  on behalf of Rob Sayre 
Sent: Tuesday, July 16, 2019 8:46:42 AM
To: Eric Rescorla 
Cc: dnsop WG ; Paul Vixie 
Subject: Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

On Tue, Jul 16, 2019 at 6:41 AM Eric Rescorla 
mailto:e...@rtfm..com>> wrote:


The certs are public information, so having the certs isn't useful. Can you 
please be clearer about the attack you are describing?

Sure, here's an article about it:
>

Do you have any thoughts on that?

thanks,
Rob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

[Tommy Jensen]

Some reasons I can think of off the top of my head:

  *   Because emails aren't always opened within the safety of corporate 
controlled networks (where DNS is controlled)
  *   Because security systems should always have fallbacks
  *   Because such a service can be sold to other companies who aren't 
otherwise interested in hosting their own DNS

I don't understand the point you're going for here, or how it relates to the 
draft in this thread's subject line.

Thanks,
Tommy

From: Rob Sayre 
Sent: Tuesday, July 16, 2019 5:10 PM
To: Tommy Jensen 
Cc: Eric Rescorla ; dnsop WG ; Paul Vixie 

Subject: Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

Hi Tommy,

I also noticed that your email client rewrote the link to "The Register", a 
site that everyone knows, which then linked to NY Times, etc.

It used the domain 
"nam06.safelinks.protection.outlook.com<http://nam06.safelinks.protection.outlook.com>".
 Why would that domain be necessary if DNS-based security worked?

thanks,
Rob


On Tue, Jul 16, 2019 at 10:32 AM Rob Sayre 
mailto:say...@gmail.com>> wrote:


On Tue, Jul 16, 2019 at 10:20 AM Tommy Jensen 
mailto:jensen.tho...@microsoft.com>> wrote:
The link you shared indicates the problem is RC4, which was removed from TLS in 
1.3 for this very reason. This doesn’t demonstrate TLS 1.3 is vulnerable; it 
demonstrates why adopting TLS 1.3 is so important.

Yeah, that's one part of it, but some of the other approaches described are 
more general.

thanks,
Rob



Thanks,
Tommy

From: DNSOP mailto:dnsop-boun...@ietf.org>> on behalf 
of Rob Sayre mailto:say...@gmail.com>>
Sent: Tuesday, July 16, 2019 8:46:42 AM
To: Eric Rescorla mailto:e...@rtfm.com>>
Cc: dnsop WG mailto:dnsop@ietf.org>>; Paul Vixie 
mailto:p...@redbarn.org>>
Subject: Re: [DNSOP] Fwd: [Add] new draft: draft-grover-add-policy-detection-00

On Tue, Jul 16, 2019 at 6:41 AM Eric Rescorla 
mailto:e...@rtfm..com>> wrote:


The certs are public information, so having the certs isn't useful. Can you 
please be clearer about the attack you are describing?

Sure, here's an article about it:
<https://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullrun_analysis/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww..theregister.co.uk%2F2013%2F09%2F06%2Fnsa_cryptobreaking_bullrun_analysis%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C51ca900221824198518208d70a4b34bd%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636989190436279112&sdata=5qVj7tNPQMSYuYKmPILW7Uws6JCtLXucxz3CbATL3Cs%3D&reserved=0>>

Do you have any thoughts on that?

thanks,
Rob
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Tommy Jensen]

> I still maintain that having descriptive terms should be preferable
over an abundance of abbreviations, particular in documents. In this
case, why not "classic DNS" or "traditional DNS"? Likewise, "encrypted
DNS" instead of DoTH.

I agree with "encrypted DNS" because that makes the meaning (DoH or DoT or X : 
X is some new way to encrypt DNS) clear when it is intended, and saying DoH/DoT 
when that is really intended (just those two and not any other encrypted 
version of DNS) isn't that burdensome. DoTH can be confused with some new 
specific protocol "DNS over T H" since that's what the other Do* 
patterns indicate.

However, I think Do53 makes sense as it includes any use of DNS over port 53 
and fits the Do* pattern used by other DNS protocols. This would only become 
confusing in the event we end up introducing an encrypted DNS protocol that 
also operates over port 53 which seems incredibly unlikely.

Thanks,
Tommy

From: DNSOP  on behalf of Martin Hoffmann 

Sent: Thursday, July 25, 2019 7:52 AM
To: Paul Hoffman 
Cc: dnsop 
Subject: Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01..txt

Paul Hoffman wrote:
> Do53 was invented as a way of saying "DNS format and transport as
> described in RFC 1034 and RFC 1035, with updates". If anyone has a
> better shorthand for that than "Do53", that's great. I believe a
> shorthand is needed, particularly for publications that are
> discussiong multiple transports.

I still maintain that having descriptive terms should be preferable
over an abundance of abbreviations, particular in documents. In this
case, why not "classic DNS" or "traditional DNS"? Likewise, "encrypted
DNS" instead of DoTH.

Kind regards,
Martin

___
DNSOP mailing list
DNSOP@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C6e63764eb3524be5ccc108d7110fd3cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996631991661796&sdata=8bdbQf45P7S53XE4DLJ9H9m0di%2FgbykgOrCPXktNdtM%3D&reserved=0
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Tommy Jensen]

Good point ("s/new/other" in my definition of "encrypted DNS"). And I agree, 
"encrypted DNS" is a superset of "DoH and DoT" but not the other way around.

Thanks,
Tommy

From: Joe Abley 
Sent: Thursday, July 25, 2019 10:24 AM
To: Tommy Jensen 
Cc: Martin Hoffmann ; Paul Hoffman 
; dnsop 
Subject: Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01..txt

On Jul 25, 2019, at 19:14, Tommy Jensen 
mailto:Jensen.Thomas=40microsoft@dmarc.ietf.org>>
 wrote:

> I still maintain that having descriptive terms should be preferable
over an abundance of abbreviations, particular in documents. In this
case, why not "classic DNS" or "traditional DNS"? Likewise, "encrypted
DNS" instead of DoTH.

I agree with "encrypted DNS" because that makes the meaning (DoH or DoT or X : 
X is some new way to encrypt DNS) clear when it is intended

Like DNSCrypt with UDP transport?

Or like an apex TXT record that contains a one-time token to authenticate a 
zone to a service?

I spent some time this week at the Africa DNS Forum in Botswana promoting the 
idea that the concept of "DNS Security" is usefully more broad than just 
DNSSEC. Perhaps we need a corresponding effort to broaden "DNS Encryption" 
beyond DoH and DoT?


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Tommy Jensen]

The 53U, 53T, 53UT ordering makes more sense to me, since it aligns with the 
DoH/DoT alignment of protocol indicator followed by transport indicator 
ordering.

From: DNSOP  on behalf of Paul Wouters 
Sent: Thursday, July 25, 2019 10:29 AM
To: Evan Hunt 
Cc: dnsop 
Subject: Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

On Thu, 25 Jul 2019, Evan Hunt wrote:

> "Do53" is a handy abbreviation, but I'm concerned that using it as a
> coequal peer of DoT and DoH will lead to fuzzy thinking.

Indeed. U53, T53 and UT53 (or 53U, 53T, 53UT) would be far more informative..

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca83a347f25ef461c263708d71125b5a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996725966251868&sdata=l29PLDfowCk0761lJXtpG4%2FZEvgf8nSkmKWLZ8HxcFE%3D&reserved=0
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter

[Tommy Jensen]

> > In favour of adoption. Simple, short and clear document.

> +1

+1

From: DNSOP  on behalf of Jim Reid 
Sent: Thursday, August 1, 2019 10:08 AM
To: Paul Wouters 
Cc: Tim Wicinski ; dnsop 
Subject: Re: [DNSOP] Call for Adoption: draft-hoffman-dns-terminology-ter



> On 1 Aug 2019, at 18:04, Paul Wouters  wrote:
>
> In favour of adoption. Simple, short and clear document.

+1

___
DNSOP mailing list
DNSOP@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cc5730243858c4e50932808d716a2faa2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637002761571689067&sdata=L1Eo%2BvUOQvfl6rF0NihzWSjJzl5t0D%2BvF355VAaIvzA%3D&reserved=0
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Re: [EXTERNAL] Re: New draft regarding RFC7050

[Tommy Jensen]

Hey Florian,

Thank you for the feedback, and thank you for sharing your draft. My main 
concern with your -00 is the introduction of yet another mechanism for 
discovering the prefix: 

  The DNS resolver MAY return an IPv6 prefix or a comma separated
  list of prefixes to indicate not just that DNS64 is being
  performed but also to let the client know which prefix or prefixes
  are in use.  The prefixes MUST be represented using the canonical
  representation format of [RFC5952].

Please do not give implementors the temptation. We do not need another 
discovery mechanism and the conflict resolution guidance that would require. 

Thanks,
Tommy

> -Original Message-
> From: Florian Obser 
> Sent: Monday, October 21, 2024 7:43 AM
> To: Nick Buraglio 
> Cc: dnsop@ietf.org; Jen Linkova ; Tommy Jensen
> 
> Subject: [EXTERNAL] Re: [DNSOP] New draft regarding RFC7050
> 
> On 2024-09-09 17:51 -05, Nick Buraglio  wrote:
> > dnsop folks,
> >
> > Based on some conversations and discussions at the end of the second
> > session at 120, several of us worked out a draft to address what we
> > believe are some notable details in RFC7050. This draft was just
> > submitted to the datatracker, and we would appreciate any input,
> > comments, corrections, and productive discussion from the expertise of
> > the group. The draft can be read at
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> > tracker.ietf.org%2Fdoc%2Fdraft-buraglio-deprecate7050%2F&data=05%7C02%
> >
> 7CJensen.Thomas%40microsoft.com%7Cd8fc7fd951164c6fef2108dcf1dea66d%7
> C7
> >
> 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638651185889707957%7CU
> nknown
> >
> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJ
> >
> XVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Z0wnaQB6DepNHsEOTTQoEwKDSSaVp
> V%2BmixKSZ
> > e2dnFE%3D&reserved=0
> >
> > Thanks in advance, we look forward to anything the list is willing to
> > provide.
> 
> I think this plain needs killing, RFC8781 is so much better.
> 
> It occurred to me that a validating stub resolver still needs to know if its 
> upstream
> is messing with DNS. With RFC9606 we can just ask the resolver what it's 
> doing,
> so I put up
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatrack
> er.ietf.org%2Fdoc%2Fdraft-fobser-resinfo-
> dns64%2F&data=05%7C02%7CJensen.Thomas%40microsoft.com%7Cd8fc7fd951
> 164c6fef2108dcf1dea66d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C638651185889729988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
> a=RzAZTujnuR79y7vYjzkJSFdUidrcq1YqJZszZbW5TOI%3D&reserved=0
> 
> A validating stub can then avoid that resolver or do more fancy things like 
> spotting
> that the resolver did DNS64 synthesis, ignore that answer and do its own
> synthesis using the 8781 prefix...
> 
> >
> > Thanks!
> >
> > nb
> > ___
> > DNSOP mailing list -- dnsop@ietf.org
> > To unsubscribe send an email to dnsop-le...@ietf.org
> >
> 
> --
> In my defence, I have been left unsupervised.

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [EXTERNAL] Re: New Version Notification for draft-momoka-dnsop-3901bis-06.txt

[Tommy Jensen]

I'm happy to see 3901 being updated and this draft getting updated from list 
discussion. Having read through the previous list discussion, I don't have 
additional feedback of substance other than "this is worth working on and I 
would support adoption if a CfA occurred".

Minor suggested edits: (1) through Section 4.1, "MUST not" should probably be 
"MUST NOT" and (2) "legacy IP" and "IPv4" should be standardized (only use one 
of them) unless there's some context-appropriate reason for these to be used I 
do not understand. 

Thanks,
Tommy
 

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org