[DNSOP]Fwd: New Version Notification for draft-momoka-dnsop-3901bis-05.txt

[Momoka Yamamoto]

Hi dnsop wg.
We have submitted an update to our rfc3901bis draft "DNS IPv6 Transport
Operational Guidelines."

The changes can be seen below.
Diff from v3 to v5(current):
https://author-tools.ietf.org/iddiff?url1=draft-momoka-dnsop-3901bis-03=draft-momoka-dnsop-3901bis-05=--html

The main difference from the previous version is the addition of the
following, after Geoff's comments on DNS over UDP/IPv6 not working properly
on large responses.
We added a reference to I-D.ietf-dnsop-avoid-fragmentation to address the
problem of IP fragmentation with IPv6.

```
Avoiding Fragmentation:
   IP fragmentation has been reported to be fragile [RFC8900].
   Therefore, IP fragmentation should be avoided in order to treat
   both IPv4/IPv6 equally [I-D.ietf-dnsop-avoid-fragmentation].
```

I hope to hear from the community about how this document can be improved.

Momoka

-- Forwarded message -
From: 
Date: Tue, Apr 30, 2024 at 3:10 PM
Subject: New Version Notification for draft-momoka-dnsop-3901bis-05.txt
To: Momoka Yamamoto , Tobias Fiebig <
tfie...@mpi-inf.mpg.de>


A new version of Internet-Draft draft-momoka-dnsop-3901bis-05.txt has been
successfully submitted by Momoka Yamamoto and posted to the
IETF repository.

Name: draft-momoka-dnsop-3901bis
Revision: 05
Title:DNS IPv6 Transport Operational Guidelines
Date: 2024-04-30
Group:Individual Submission
Pages:9
URL:  https://www.ietf.org/archive/id/draft-momoka-dnsop-3901bis-05.txt
Status:   https://datatracker.ietf.org/doc/draft-momoka-dnsop-3901bis/
HTML: https://www.ietf.org/archive/id/draft-momoka-dnsop-3901bis-05.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-momoka-dnsop-3901bis
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-momoka-dnsop-3901bis-05

Abstract:

   This memo provides guidelines and documents Best Current Practice for
   operating authoritative and recursive DNS servers, given that queries
   and responses are carried in a mixed environment of IPv4 and IPv6
   networks.  It expands on RFC 3901 by now suggesting authoritative and
   iterative resolvers to operate on both IPv4 and IPv6.

   This document obsoletes RFC3901. (if approved)

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/momoka0122y/draft-dnsop-3901bis.



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

Re: [DNSOP] Fwd: New Version Notification for draft-heard-dnsop-udp-opt-large-dns-responses-00.txt

[C. M. Heard]

Thank you for your reply. I have added some comments in-line.

On Thu, May 2, 2024 at 10:42 AM Ben Schwartz wrote:

> It seems like this draft says that the indicated MRDS overrides the EDNS
> BUFSIZE value.  This seems likely to create problems if the MRDS value
> could be set by a lower layer in the stack or a downstream processing
> component (without knowledge of DNS), resulting in responses that are too
> large for the DNS client's allocated buffer.  In other words, just because
> I am capable of receiving very large UDP packets does not mean that I am
> capable of processing very large DNS responses.
>

This actually should not be a concern, as the intent is that UDP options
are sent, or responded to, ONLY at the explicit behest of the upper layer.
In other words they are always opt-in. In this instance, the upper layer
would have to explicitly ask for the MRDS option to be included in the
outgoing request, and would have to set the MRDS size appropriately (which
would mean, the lesser of its own buffer capacity and what the system would
support).


> In general, support for very large DNS responses in UDP is considered
> harmful because of the potential for reflection-amplification attacks.  For
> this reason, as well as concerns about legacy compatibility and general
> complexity, I think we would be better off not attempting to use UDP
> Options with DNS.
>

Point taken - fallback to TCP does not have this particular vulnerability.

Respectfully,

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

Re: [DNSOP] Fwd: New Version Notification for draft-heard-dnsop-udp-opt-large-dns-responses-00.txt

[Ben Schwartz]

It seems like this draft says that the indicated MRDS overrides the EDNS 
BUFSIZE value.  This seems likely to create problems if the MRDS value could be 
set by a lower layer in the stack or a downstream processing component (without 
knowledge of DNS), resulting in responses that are too large for the DNS 
client's allocated buffer.  In other words, just because I am capable of 
receiving very large UDP packets does not mean that I am capable of processing 
very large DNS responses.

In general, support for very large DNS responses in UDP is considered harmful 
because of the potential for reflection-amplification attacks.  For this 
reason, as well as concerns about legacy compatibility and general complexity, 
I think we would be better off not attempting to use UDP Options with DNS.

--Ben Schwartz

From: DNSOP  on behalf of C. M. Heard 
Sent: Sunday, April 28, 2024 5:02 PM
To: DNSOP 
Subject: [DNSOP] Fwd: New Version Notification for 
draft-heard-dnsop-udp-opt-large-dns-responses-00.txt

Greetings, TSVWG currently has the document "Transport Options for UDP" (https: 
//datatracker. ietf. org/doc/html/draft-ietf-tsvwg-udp-options) in Working 
Group Last Call. It includes a capability to fragment datagrams at the UDP layer
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd
Greetings,

TSVWG currently has the document "Transport Options for UDP" 
(https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options>)
 in Working Group Last Call. It includes a capability to fragment datagrams at 
the UDP layer rather than the IP layer, and one of the use cases that has been 
discussed over there is using that capability to transmit large DNS responses 
without suffering the disadvantages of IP fragmentation or fallback to TCP. But 
we need a reality check from the subject matter experts over here to help us 
determine whether this idea is viable. Accordingly, I put together a short (and 
at this point not very polished) individual draft describing how this might 
work. Your feedback will be greatly appreciated.

Thanks and regards,

Mike Heard

-- Forwarded message -
From: mailto:internet-dra...@ietf.org>>
Date: Sun, Apr 28, 2024 at 12:52 PM
Subject: New Version Notification for 
draft-heard-dnsop-udp-opt-large-dns-responses-00.txt
To: C. M. Heard (Mike) mailto:he...@pobox.com>>


A new version of Internet-Draft
draft-heard-dnsop-udp-opt-large-dns-responses-00.txt has been successfully
submitted by C. M. (Mike) Heard and posted to the
IETF repository.

Name: draft-heard-dnsop-udp-opt-large-dns-responses
Revision: 00
Title:Use of UDP Options for Transmission of Large DNS Responses
Date: 2024-04-28
Group:Individual Submission
Pages:8
URL:  
https://www.ietf.org/archive/id/draft-heard-dnsop-udp-opt-large-dns-responses-00.txt<https://www.ietf.org/archive/id/draft-heard-dnsop-udp-opt-large-dns-responses-00.txt>
Status:   
https://datatracker.ietf.org/doc/draft-heard-dnsop-udp-opt-large-dns-responses/<https://datatracker.ietf.org/doc/draft-heard-dnsop-udp-opt-large-dns-responses/>
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses<https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses>


Abstract:

   This document describes an experimental method for using UDP Options
   to facilitate the transmission of large DNS responses without the
   use of IP fragmentation or fallback to TCP.



The IETF Secretariat


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

[DNSOP] Fwd: New Version Notification for draft-heard-dnsop-udp-opt-large-dns-responses-00.txt

[C. M. Heard]

Greetings,

TSVWG currently has the document "Transport Options for UDP" (
https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options) in
Working Group Last Call. It includes a capability to fragment datagrams at
the UDP layer rather than the IP layer, and one of the use cases that has
been discussed over there is using that capability to transmit large DNS
responses without suffering the disadvantages of IP fragmentation or
fallback to TCP. But we need a reality check from the subject matter
experts over here to help us determine whether this idea is viable.
Accordingly, I put together a short (and at this point not very polished)
individual draft describing how this might work. Your feedback will be
greatly appreciated.

Thanks and regards,

Mike Heard

-- Forwarded message -
From: 
Date: Sun, Apr 28, 2024 at 12:52 PM
Subject: New Version Notification for
draft-heard-dnsop-udp-opt-large-dns-responses-00.txt
To: C. M. Heard (Mike) 


A new version of Internet-Draft
draft-heard-dnsop-udp-opt-large-dns-responses-00.txt has been successfully
submitted by C. M. (Mike) Heard and posted to the
IETF repository.

Name: draft-heard-dnsop-udp-opt-large-dns-responses
Revision: 00
Title:Use of UDP Options for Transmission of Large DNS Responses
Date: 2024-04-28
Group:Individual Submission
Pages:8
URL:
https://www.ietf.org/archive/id/draft-heard-dnsop-udp-opt-large-dns-responses-00.txt
Status:
https://datatracker.ietf.org/doc/draft-heard-dnsop-udp-opt-large-dns-responses/
HTMLized:
https://datatracker.ietf.org/doc/html/draft-heard-dnsop-udp-opt-large-dns-responses


Abstract:

   This document describes an experimental method for using UDP Options
   to facilitate the transmission of large DNS responses without the
   use of IP fragmentation or fallback to TCP.



The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

[Vittorio Bertola]

> Il 11/01/2024 03:50 CET Lanlan Pan  ha scritto:
> 
> 
> Thanks Paul.
> 
> Paul Wouters  于2024年1月10日周三 23:01写道：
> > As I've said during the discussions on RBL and an updated version for
> > RBL, if these things are done "for the user", the best thing is to put
> > the censored answer in the authority section. This way ignorant clients
> > keep working with the censor, but knowledgable clients can DNSSEC validate
> > the censorship using the original answer and optionally present a choice
> > to the enduser. It also prevents censorship forced against the user's
> > interest. eg it makes this properly optin (eg compliant with RFC 8890)
> 
> The explicit faked answer signal:
> - In Format 1, it follows EDE, in additional section.
> - In Format 2 , it is an TXT RR, in authority section (same as faked answer). 
> I will revise it.
> 
> Knowledgable client can make its own reaction, if it gets a explicit signal 
> that it has received a faked answer.
> This can mitigate the HTTP cookies leak, especially on NXDOMAIN redirection 
> case.

I'm not against this, but I don't see which kind of resolver operator would 
want to use it.

There are only two possibilities:

1. the forging is made cooperatively, to protect the user themself, so the user 
actually asked the resolver to block certain destinations and send back a 
pointer to an error page; in this case, the client has no reason to try any of 
the circumvention strategies you describe in section 5, and doing this could 
actually endanger the user;

2. the forging is made adversarially, to protect other users from whatever this 
particular user is trying to do with the Internet; in this case, the server has 
no reason to tell the client that something special is happening, as it needs 
to prevent the client from circumventing the block; so it will not add any 
signal to the answer.

Even in case 2, resolvers who want to be more transparent and don't want to 
forge any answer could just say no + EDE 15-18, at least when that will be 
supported by browsers.

Can you see a use case that would motivate people to implement this new 
mechanism?

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

[Lanlan Pan]

 Thanks Paul.

Paul Wouters  于2024年1月10日周三 23:01写道：

> On Wed, 10 Jan 2024, Lanlan Pan wrote:
>
> > I have submitted a new draft to discuss the faked answer returned from
> the recursive resolver.
> >
> > Your comments are appreciated.
>
> As I've said during the discussions on RBL and an updated version for
> RBL, if these things are done "for the user", the best thing is to put
> the censored answer in the authority section. This way ignorant clients
> keep working with the censor, but knowledgable clients can DNSSEC validate
> the censorship using the original answer and optionally present a choice
> to the enduser. It also prevents censorship forced against the user's
> interest. eg it makes this properly optin (eg compliant with RFC 8890)
>

The explicit faked answer signal:
- In Format 1, it follows EDE, in additional section.
- In Format 2 , it is an TXT RR, in authority section (same as faked
answer). I will revise it.

Knowledgable client can make its own reaction, if it gets a explicit signal
that it has received a faked answer.
This can mitigate the HTTP cookies leak, especially on NXDOMAIN redirection
case.


> There should be no synthesizing of fake records as those cannot pass
> DNSSEC validation. One has to assume the querier is DNSSEC enabled,
> even if it is a stub. We already have extended error codes for
> censorship (see
> https://www.rfc-editor.org/rfc/rfc8914.html#name-iana-considerations
> error codes 15-18)
>

The faked answer(A/CNAME RR): is at authority section now.
Assume that the client is DNSSEC enable, if the target domain has deployed
DNSSEC, then the client could make DNSSEC validation, and the faked answer
cannot pass the validation.
Format 1 could reuse the EDE error codes 15-18.


> Paul
>
> > -- Forwarded message -
> > 发件人： 
> > Date: 2024年1月10日周三 16:11
> > Subject: New Version Notification for
> draft-pan-dnsop-explicit-forged-answer-signal-00.txt
> > To: Lanlan Pan 
> >
> >
> > A new version of Internet-Draft
> > draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been
> successfully
> > submitted by Lanlan Pan and posted to the
> > IETF repository.
> >
> > Name: draft-pan-dnsop-explicit-forged-answer-signal
> > Revision: 00
> > Title:Explicit Forged Answer Signal
> > Date: 2024-01-10
> > Group:Individual Submission
> > Pages:6
> > URL:
> https://www.ietf.org/archive/id/draft-pan-dnsop-explicit-forged-answer-signal-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-pan-dnsop-explicit-forged-answer-signal/
> > HTMLized:
> https://datatracker.ietf.org/doc/html/draft-pan-dnsop-explicit-forged-answer-signal
> >
> >
> > Abstract:
> >
> >This document describes that recursive resolver should give explict
> >signal in the forged answer.
> >
> >Client could react more clearly based on the explict forged answer
> >signal, to protect user on security and privacy.
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
> >
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

[Paul Wouters]

On Jan 10, 2024, at 20:55, Paul Vixie  wrote:
> 
> i think you mean RPZ here.

Yes I did. Thank you.

Paul

> 
> Paul Wouters wrote on 2024-01-10 07:01:
>>> On Wed, 10 Jan 2024, Lanlan Pan wrote:
>>> I have submitted a new draft to discuss the faked answer returned from the 
>>> recursive resolver.
>>> 
>>> Your comments are appreciated.
>> As I've said during the discussions on RBL and an updated version for
>> RBL, if these things are done "for the user", the best thing is to put
>> the censored answer in the authority section. This way ignorant clients
>> keep working with the censor, but knowledgable clients can DNSSEC validate
>> the censorship using the original answer and optionally present a choice
>> to the enduser. It also prevents censorship forced against the user's
>> interest. eg it makes this properly optin (eg compliant with RFC 8890)
>> There should be no synthesizing of fake records as those cannot pass
>> DNSSEC validation. One has to assume the querier is DNSSEC enabled,
>> even if it is a stub. We already have extended error codes for
>> censorship (see 
>> https://www.rfc-editor.org/rfc/rfc8914.html#name-iana-considerations
>> error codes 15-18)
>> Paul
>>> -- Forwarded message -
>>> 发件人： 
>>> Date: 2024年1月10日周三 16:11
>>> Subject: New Version Notification for 
>>> draft-pan-dnsop-explicit-forged-answer-signal-00.txt
>>> To: Lanlan Pan 
>>> 
>>> 
>>> A new version of Internet-Draft
>>> draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been successfully
>>> submitted by Lanlan Pan and posted to the
>>> IETF repository.
>>> 
>>> Name: draft-pan-dnsop-explicit-forged-answer-signal
>>> Revision: 00
>>> Title:Explicit Forged Answer Signal
>>> Date: 2024-01-10
>>> Group:Individual Submission
>>> Pages:6
>>> URL:  
>>> https://www.ietf.org/archive/id/draft-pan-dnsop-explicit-forged-answer-signal-00.txt
>>> Status:   
>>> https://datatracker.ietf.org/doc/draft-pan-dnsop-explicit-forged-answer-signal/
>>> HTMLized: 
>>> https://datatracker.ietf.org/doc/html/draft-pan-dnsop-explicit-forged-answer-signal
>>> 
>>> 
>>> Abstract:
>>> 
>>>This document describes that recursive resolver should give explict
>>>signal in the forged answer.
>>> 
>>>Client could react more clearly based on the explict forged answer
>>>signal, to protect user on security and privacy.
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>>> 
>>> 
>>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> --
> P Vixie
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

[Lanlan Pan]

Thanks Bob,  I will revised it.

Bob Harold  于2024年1月10日周三 22:23写道：

>
> On Wed, Jan 10, 2024 at 4:19 AM Lanlan Pan  wrote:
>
>> Hi all,
>>
>> I have submitted a new draft to discuss the faked answer returned from
>> the recursive resolver.
>>
>> Your comments are appreciated.
>>
>>
>> -- Forwarded message -
>> 发件人： 
>> Date: 2024年1月10日周三 16:11
>> Subject: New Version Notification for
>> draft-pan-dnsop-explicit-forged-answer-signal-00.txt
>> To: Lanlan Pan 
>>
>>
>> A new version of Internet-Draft
>> draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been successfully
>> submitted by Lanlan Pan and posted to the
>> IETF repository.
>>
>> Name: draft-pan-dnsop-explicit-forged-answer-signal
>> Revision: 00
>> Title:Explicit Forged Answer Signal
>> Date: 2024-01-10
>> Group:Individual Submission
>> Pages:6
>> URL:
>> https://www.ietf.org/archive/id/draft-pan-dnsop-explicit-forged-answer-signal-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-pan-dnsop-explicit-forged-answer-signal/
>> HTMLized:
>> https://datatracker.ietf.org/doc/html/draft-pan-dnsop-explicit-forged-answer-signal
>>
>>
>> Abstract:
>>
>>This document describes that recursive resolver should give explict
>>signal in the forged answer.
>>
>>Client could react more clearly based on the explict forged answer
>>signal, to protect user on security and privacy.
>>
>>
> Without commenting on the merits of this,
> This section:
>
> 1.  Background and Motivation
>
>Recursive server may replace a forged answer to a query with a
>configured answer of the authoritative server
>
> Seems reversed.  It should be:
>
> 1.  Background and Motivation
>
>Recursive server may replace a configured answer to a query
>from the authoritative server with a forged answer
>
>  --
> Bob Harold
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

[Paul Vixie]

i think you mean RPZ here.

Paul Wouters wrote on 2024-01-10 07:01:

On Wed, 10 Jan 2024, Lanlan Pan wrote:

I have submitted a new draft to discuss the faked answer returned from 
the recursive resolver.


Your comments are appreciated.


As I've said during the discussions on RBL and an updated version for
RBL, if these things are done "for the user", the best thing is to put
the censored answer in the authority section. This way ignorant clients
keep working with the censor, but knowledgable clients can DNSSEC validate
the censorship using the original answer and optionally present a choice
to the enduser. It also prevents censorship forced against the user's
interest. eg it makes this properly optin (eg compliant with RFC 8890)

There should be no synthesizing of fake records as those cannot pass
DNSSEC validation. One has to assume the querier is DNSSEC enabled,
even if it is a stub. We already have extended error codes for
censorship (see 
https://www.rfc-editor.org/rfc/rfc8914.html#name-iana-considerations

error codes 15-18)

Paul


-- Forwarded message -
发件人： 
Date: 2024年1月10日周三 16:11
Subject: New Version Notification for 
draft-pan-dnsop-explicit-forged-answer-signal-00.txt

To: Lanlan Pan 


A new version of Internet-Draft
draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been 
successfully

submitted by Lanlan Pan and posted to the
IETF repository.

Name:     draft-pan-dnsop-explicit-forged-answer-signal
Revision: 00
Title:    Explicit Forged Answer Signal
Date:     2024-01-10
Group:    Individual Submission
Pages:    6
URL:  
https://www.ietf.org/archive/id/draft-pan-dnsop-explicit-forged-answer-signal-00.txt 

Status:  
 https://datatracker.ietf.org/doc/draft-pan-dnsop-explicit-forged-answer-signal/ 

HTMLized: 
https://datatracker.ietf.org/doc/html/draft-pan-dnsop-explicit-forged-answer-signal 




Abstract:

   This document describes that recursive resolver should give explict
   signal in the forged answer.

   Client could react more clearly based on the explict forged answer
   signal, to protect user on security and privacy.



The IETF Secretariat






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



--
P Vixie

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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

[Paul Wouters]

On Wed, 10 Jan 2024, Lanlan Pan wrote:


I have submitted a new draft to discuss the faked answer returned from the 
recursive resolver.

Your comments are appreciated.


As I've said during the discussions on RBL and an updated version for
RBL, if these things are done "for the user", the best thing is to put
the censored answer in the authority section. This way ignorant clients
keep working with the censor, but knowledgable clients can DNSSEC validate
the censorship using the original answer and optionally present a choice
to the enduser. It also prevents censorship forced against the user's
interest. eg it makes this properly optin (eg compliant with RFC 8890)

There should be no synthesizing of fake records as those cannot pass
DNSSEC validation. One has to assume the querier is DNSSEC enabled,
even if it is a stub. We already have extended error codes for
censorship (see 
https://www.rfc-editor.org/rfc/rfc8914.html#name-iana-considerations
error codes 15-18)

Paul


-- Forwarded message -
发件人： 
Date: 2024年1月10日周三 16:11
Subject: New Version Notification for 
draft-pan-dnsop-explicit-forged-answer-signal-00.txt
To: Lanlan Pan 


A new version of Internet-Draft
draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been successfully
submitted by Lanlan Pan and posted to the
IETF repository.

Name:     draft-pan-dnsop-explicit-forged-answer-signal
Revision: 00
Title:    Explicit Forged Answer Signal
Date:     2024-01-10
Group:    Individual Submission
Pages:    6
URL:      
https://www.ietf.org/archive/id/draft-pan-dnsop-explicit-forged-answer-signal-00.txt
Status:   
https://datatracker.ietf.org/doc/draft-pan-dnsop-explicit-forged-answer-signal/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-pan-dnsop-explicit-forged-answer-signal


Abstract:

   This document describes that recursive resolver should give explict
   signal in the forged answer.

   Client could react more clearly based on the explict forged answer
   signal, to protect user on security and privacy.



The IETF Secretariat






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

Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

[Bob Harold]

On Wed, Jan 10, 2024 at 4:19 AM Lanlan Pan  wrote:

> Hi all,
>
> I have submitted a new draft to discuss the faked answer returned from the
> recursive resolver.
>
> Your comments are appreciated.
>
>
> -- Forwarded message -
> 发件人： 
> Date: 2024年1月10日周三 16:11
> Subject: New Version Notification for
> draft-pan-dnsop-explicit-forged-answer-signal-00.txt
> To: Lanlan Pan 
>
>
> A new version of Internet-Draft
> draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been successfully
> submitted by Lanlan Pan and posted to the
> IETF repository.
>
> Name: draft-pan-dnsop-explicit-forged-answer-signal
> Revision: 00
> Title:Explicit Forged Answer Signal
> Date: 2024-01-10
> Group:Individual Submission
> Pages:6
> URL:
> https://www.ietf.org/archive/id/draft-pan-dnsop-explicit-forged-answer-signal-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-pan-dnsop-explicit-forged-answer-signal/
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-pan-dnsop-explicit-forged-answer-signal
>
>
> Abstract:
>
>This document describes that recursive resolver should give explict
>signal in the forged answer.
>
>Client could react more clearly based on the explict forged answer
>signal, to protect user on security and privacy.
>
>
Without commenting on the merits of this,
This section:

1.  Background and Motivation

   Recursive server may replace a forged answer to a query with a
   configured answer of the authoritative server

Seems reversed.  It should be:

1.  Background and Motivation

   Recursive server may replace a configured answer to a query
   from the authoritative server with a forged answer

 --
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-pan-dnsop-explicit-forged-answer-signal-00.txt

[Lanlan Pan]

Hi all,

I have submitted a new draft to discuss the faked answer returned from the
recursive resolver.

Your comments are appreciated.


-- Forwarded message -
发件人： 
Date: 2024年1月10日周三 16:11
Subject: New Version Notification for
draft-pan-dnsop-explicit-forged-answer-signal-00.txt
To: Lanlan Pan 


A new version of Internet-Draft
draft-pan-dnsop-explicit-forged-answer-signal-00.txt has been successfully
submitted by Lanlan Pan and posted to the
IETF repository.

Name: draft-pan-dnsop-explicit-forged-answer-signal
Revision: 00
Title:Explicit Forged Answer Signal
Date: 2024-01-10
Group:Individual Submission
Pages:6
URL:
https://www.ietf.org/archive/id/draft-pan-dnsop-explicit-forged-answer-signal-00.txt
Status:
https://datatracker.ietf.org/doc/draft-pan-dnsop-explicit-forged-answer-signal/
HTMLized:
https://datatracker.ietf.org/doc/html/draft-pan-dnsop-explicit-forged-answer-signal


Abstract:

   This document describes that recursive resolver should give explict
   signal in the forged answer.

   Client could react more clearly based on the explict forged answer
   signal, to protect user on security and privacy.



The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-lenders-dns-cbor-05.txt

[Martine Sophie Lenders]

FYI


 Forwarded Message 
Subject: New Version Notification for draft-lenders-dns-cbor-05.txt
Resent-From: martine.lend...@tu-dresden.de
Date: Mon, 23 Oct 2023 19:55:59 +
From: internet-dra...@ietf.org 
To: Thomas C. Schmidt , Matthias Waehlisch 
, Carsten Bormann , 
Martine Lenders , Martine Lenders 
, Matthias Waehlisch 
, Thomas Schmidt 



A new version of Internet-Draft draft-lenders-dns-cbor-05.txt has been
successfully submitted by Martine Lenders and posted to the
IETF repository.

Name: draft-lenders-dns-cbor
Revision: 05
Title:A Concise Binary Object Representation (CBOR) of DNS Messages
Date: 2023-10-23
Group:Individual Submission
Pages:20
URL:  https://www.ietf.org/archive/id/draft-lenders-dns-cbor-05.txt
Status:   https://datatracker.ietf.org/doc/draft-lenders-dns-cbor/
HTML: https://www.ietf.org/archive/id/draft-lenders-dns-cbor-05.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-lenders-dns-cbor
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-lenders-dns-cbor-05


Abstract:

   This document specifies a compressed data format of DNS messages
   using the Concise Binary Object Representation [RFC8949].  The
   primary purpose is to keep DNS messages small in constrained
   networks.



The IETF Secretariat




smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-ietf-core-dns-over-coap-04.txt

[Martine Sophie Lenders]

FYI

 Forwarded Message 
Subject: New Version Notification for draft-ietf-core-dns-over-coap-04.txt
Resent-From: martine.lend...@tu-dresden.de
Date: Mon, 23 Oct 2023 19:47:01 +
From: internet-dra...@ietf.org 
To: Thomas C. Schmidt , Cenk Gündoğan 
, Christian Amsüss , 
Matthias Waehlisch , Cenk Gundogan 
, Christian Amsuess , 
Martine Lenders , Martine Lenders 
, Matthias Waehlisch 
, Thomas Schmidt 



A new version of Internet-Draft draft-ietf-core-dns-over-coap-04.txt has 
been

successfully submitted by Martine Lenders and posted to the
IETF repository.

Name: draft-ietf-core-dns-over-coap
Revision: 04
Title:DNS over CoAP (DoC)
Date: 2023-10-23
Group:core
Pages:16
URL: 
https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-04.txt

Status:   https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/
HTML: 
https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-04.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-ietf-core-dns-over-coap-04


Abstract:

   This document defines a protocol for sending DNS messages over the
   Constrained Application Protocol (CoAP).  These CoAP messages are
   protected by DTLS-Secured CoAP (CoAPS) or Object Security for
   Constrained RESTful Environments (OSCORE) to provide encrypted DNS
   message exchange for constrained devices in the Internet of Things
   (IoT).



The IETF Secretariat




smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-peltan-edns-presentation-format-01.txt

[Ben Schwartz]

Thanks!  I think this is an improvement.  Ideally this would use an existing 
schema language instead of inventing a new one, but your approach here seems 
reasonable.

I think the draft should probably add Mnemonic and Data Type columns to the 
EDNS OPT registry, to make sure that future opcodes are representable.

Nits:

Looking at dig output, I see that the built-in fields are represented in a 
manner that is clearly distinct from the option-codes:

; EDNS: version: 0, flags: do; udp: 1232
; OPT=15: 00 14 ("..")

I think you could accomplish a similar effect (and reduce divergence from dig) 
by changing "Version", "FLAGS", "RCODE" and "UDPSIZE" to lower-case.

The LLQ option seems like it would benefit from an "object" type instead of 
"list".

Section 13 (on escaping) highlights what a mess we have with weird characters 
in DNS names and zone files.  This was a big pain in SVCB with 
character-strings and comma-separated lists, and continues to be a big pain in 
other drafts (e.g. [1]).  I think we might want to invest some time in a proper 
standard for ASCII representation of DNS names.

--Ben

[1] 
https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-alias-proxy-status-05#section-2.1


From: DNSOP  on behalf of libor.peltan 

Sent: Friday, October 20, 2023 11:15 AM
To: Ben Schwartz ; libor.peltan 
; Tom Carpay ; dnsop 

Subject: Re: [DNSOP] Fwd: New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Hi Ben, DNSOP, thank you so much for your reading and comments. We considered 
both of your suggestions useful, and substantially updated the document to 
reflect them: - for each EDNS option, abstract name, type and value are 
defined, and both
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

Hi Ben, DNSOP,


thank you so much for your reading and comments. We considered both of your 
suggestions useful, and substantially updated the document to reflect them:

 - for each EDNS option, abstract name, type and value are defined, and both 
presentation and JSON formats are derived from those, leading to mutual 
unification

 - the presentation format is as similar as arguably possible to current 
dig/kdig text output


The new version of the draft can be seen here: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-02.html<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-02.html>


We also already have a piece of "running code": kdig 3.3.2 implements both JSON 
and presentation format in accordance to the draft.


We think this might be of interest of DNSOP.


Thanks,


Libor


Dne 29. 08. 23 v 19:01 Ben Schwartz napsal(a):
I have reviewed this draft.  It seems potentially useful and like a reasonable 
attempt to define a solution.

I would like to see a unified rule connecting the text and JSON 
representations, rather than explicitly defining new formats for each key (and 
in some cases even changing the key names, e.g. NSID vs. NSIDHEX).  For 
example, some options could be defined as having "list" type output, and then 
we could define generically how list values are represented in JSON and text.  
Similarly for numbers, strings, etc.  Alternatively, the JSON format could be 
defined first, and the text format could be defined via an algorithm that acts 
generically on the JSON values.

I think it's worth taking a close look at the existing commonly used 
presentation formats before defining a new one.  For example, it might be 
worthwhile to standardize a text representation that is closer to the current 
"dig" output, for the sake of compatibility with existing systems.

--Ben Schwartz

From: DNSOP <mailto:dnsop-boun...@ietf.org> on behalf 
of libor.peltan 
<mailto:libor.peltan=40nic...@dmarc.ietf.org>
Sent: Wednesday, May 31, 2023 4:33 AM
To: dnsop <mailto:dnsop@ietf.org>
Subject: [DNSOP] Fwd: New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Hi dsnop, we'd like to turn your attention again to our draft https: //www. 
ietf. org/archive/id/draft-peltan-edns-presentation-format-01. html We believe 
this document shall fill a missing gap in specifications, and help 
interoperability of DNS
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

Hi dsnop,

we'd like to turn your attention again to our draft 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html>

We believe this document shall fill a missing gap in specifications, and help 
interoperability of DNS tools. Therefore, we think it'd make sense if this 
document once becomes a dnsop-homed RFC.

We'd appreciate your feedback and comments.

Update from -00: added Guidelines for Fu

Re: [DNSOP] Fwd: New Version Notification for draft-peltan-edns-presentation-format-01.txt

[libor.peltan]

Hi Ben, DNSOP,


thank you so much for your reading and comments. We considered both of 
your suggestions useful, and substantially updated the document to 
reflect them:


 - for each EDNS option, abstract name, type and value are defined, and 
both presentation and JSON formats are derived from those, leading to 
mutual unification


 - the presentation format is as similar as arguably possible to 
current dig/kdig text output



The new version of the draft can be seen here: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-02.html



We also already have a piece of "running code": kdig 3.3.2 implements 
both JSON and presentation format in accordance to the draft.



We think this might be of interest of DNSOP.


Thanks,


Libor


Dne 29. 08. 23 v 19:01 Ben Schwartz napsal(a):
I have reviewed this draft.  It seems potentially useful and like a 
reasonable attempt to define a solution.


I would like to see a unified rule connecting the text and JSON 
representations, rather than explicitly defining new formats for each 
key (and in some cases even changing the key names, e.g. NSID vs. 
NSIDHEX).  For example, some options could be defined as having "list" 
type output, and then we could define generically how list values are 
represented in JSON and text. Similarly for numbers, strings, etc.  
Alternatively, the JSON format could be defined first, and the text 
format could be defined via an algorithm that acts generically on the 
JSON values.


I think it's worth taking a close look at the existing commonly used 
presentation formats before defining a new one.  For example, it might 
be worthwhile to standardize a text representation that is closer to 
the current "dig" output, for the sake of compatibility with existing 
systems.


--Ben Schwartz

*From:* DNSOP  on behalf of libor.peltan 


*Sent:* Wednesday, May 31, 2023 4:33 AM
*To:* dnsop 
*Subject:* [DNSOP] Fwd: New Version Notification for 
draft-peltan-edns-presentation-format-01.txt
Hi dsnop, we'd like to turn your attention again to our draft 
https: //www. ietf. org/archive/id/draft-peltan-edns-presentation-format-01. html 
We believe this document shall fill a missing gap in specifications, 
and help interoperability of DNS

ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
ZjQcmQRYFpfptBannerEnd

Hi dsnop,

we'd like to turn your attention again to our draft 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html 
<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html>


We believe this document shall fill a missing gap in specifications, 
and help interoperability of DNS tools. Therefore, we think it'd make 
sense if this document once becomes a dnsop-homed RFC.


We'd appreciate your feedback and comments.

Update from -00: added Guidelines for Future EDNS(0) Options (thanks 
to Pieter Lexis); nitpicks.


Thank you!

Libor and Tom



 Přeposlaná zpráva 
Předmět: 	New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Datum:  Wed, 31 May 2023 01:30:33 -0700
Od: internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
Komu: 	Libor Peltan  
<mailto:libor.pel...@nic.cz>, Tom Carpay  
<mailto:tomcar...@gmail.com>





A new version of I-D, draft-peltan-edns-presentation-format-01.txt
has been successfully submitted by Libor Peltan and posted to the
IETF repository.

Name: draft-peltan-edns-presentation-format
Revision: 01
Title: EDNS Presentation and JSON Format
Document date: 2023-05-31
Group: Individual Submission
Pages: 20
URL: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt 
<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt>
Status: 
https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/ 
<https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/>
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format 
<https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format>
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01 
<https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01>


Abstract:
This document describes textual and JSON representation format of
EDNS option. It also modifies the escaping rules of JSON
representation of DNS messages, previously defined in RFC8427.



The IETF Secretariat



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

Re: [DNSOP] Fwd: New Version Notification for draft-many-dnsop-dns-isolated-networks-00.txt

[Paul Wouters]

On Oct 9, 2023, at 10:02, Ben Schwartz  wrote:
> 
> 
> This is fun to think about, but it seems to me that these networks should 
> avoid any reliance on the ICANN DNS tree.  I doubt that any network of space 
> probes on Io can accept the risk of a technical or governance issue on .io.
> 
> Regardless, I think the draft would more helpful if drawn from real-world(s) 
> systems, rather than speculating about architectures that might apply in some 
> distant hypothetical scenario.

I agree. UUCP seems a better fit here, with DNS resolving happening on the 
earthly receiver side 

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

Re: [DNSOP] Fwd: New Version Notification for draft-many-dnsop-dns-isolated-networks-00.txt

[George Michaelson]

I wonder if some kind of "limited licence local signing key" model
could be used, to get a signed permit from a "real" TA in the DNS to
specify the zone(s) that a limited licence key could use, with a far
longer than normal time over the rights signing. Because we don't want
inflated lifetimes/validity intervals at large, but you probably need
something which can sustain the long delay component here.

The absence of repudiation in this model (which was conscious and
deliberate as I understand it, rejecting CRLs) means there's no easy
mechanism to say "I changed my mind" over long lived things.

Long ago, Australia operated a national DNS model which had a 9600
"dns & ntp only, munnari mostly" link behind it, which allowed one
node to sync and certify into the root. It wasn't formal, it was self
policed, and it pre-dated widescale IP connectivity (from memory, 3 or
4 universities in Melbourne plus the CSIRO had access) -which meant we
could get on with using IP in a local context but remain connected to
the namespace through a thin long wire. I'm not sure it actually had
any advantage over a periodic re-sync from a zone state, other than
being 'the IPv4, just a bit constrained'

This isn't the only proposal in name to address processes which harks
back to HOSTS.TXT, I am sure others have (it may be I have been
reading other things in the same space about interplanetary internet)
-And maybe the way forward is to focus on the complete zone, and
signed states (ZONEMD?) over the complete zone which could establish
trust, and not demand new/different TA structures?

-G

On Mon, Oct 9, 2023 at 5:18 AM Marc Blanchet  wrote:
>
> Hello,
>  The primary use case of this draft is the deployment of naming 
> infrastructure on celestial bodies networks, but could be applied for other 
> use cases.
>
> Would love to get people reviews and comments.
>
> Marc.
>
> Début du message transféré :
>
> De: internet-dra...@ietf.org
> Objet: New Version Notification for 
> draft-many-dnsop-dns-isolated-networks-00.txt
> Date: 8 octobre 2023 à 15:16:10 HAE
> À: "Marc Blanchet" 
>
> A new version of Internet-Draft draft-many-dnsop-dns-isolated-networks-00.txt
> has been successfully submitted by Marc Blanchet and posted to the
> IETF repository.
>
> Name: draft-many-dnsop-dns-isolated-networks
> Revision: 00
> Title:Domain Name System in Mostly Isolated Networks
> Date: 2023-10-08
> Group:Individual Submission
> Pages:7
> URL:  
> https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-many-dnsop-dns-isolated-networks/
> HTML: 
> https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-many-dnsop-dns-isolated-networks
>
>
> Abstract:
>
>   This document lists operational methods to enable local DNS name
>   resolving on an isolated network, where that network have
>   intermittent reachability to Internet and/or have very long delays,
>   disabling the real-time query and response flow to the authoritative
>   name servers on Internet.
>
>
>
> The IETF Secretariat
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

Re: [DNSOP] Fwd: New Version Notification for draft-many-dnsop-dns-isolated-networks-00.txt

[Ben Schwartz]

This is fun to think about, but it seems to me that these networks should avoid 
any reliance on the ICANN DNS tree.  I doubt that any network of space probes 
on Io can accept the risk of a technical or governance issue on .io.

Regardless, I think the draft would more helpful if drawn from real-world(s) 
systems, rather than speculating about architectures that might apply in some 
distant hypothetical scenario.  (If some of the proposed architectures are 
inspired by real systems, I suggest adding citations to that effect.)

--Ben Schwartz

From: DNSOP  on behalf of Marc Blanchet 

Sent: Sunday, October 8, 2023 3:17 PM
To: dnsop@ietf.org 
Subject: [DNSOP] Fwd: New Version Notification for 
draft-many-dnsop-dns-isolated-networks-00.txt

Hello, The primary use case of this draft is the deployment of naming 
infrastructure on celestial bodies networks, but could be applied for other use 
cases. Would love to get people reviews and comments. Marc. Début du message 
transféré :De: 
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
You have not previously corresponded with this sender.

ZjQcmQRYFpfptBannerEnd
Hello,
 The primary use case of this draft is the deployment of naming infrastructure 
on celestial bodies networks, but could be applied for other use cases.

Would love to get people reviews and comments.

Marc.

Début du message transféré :

De: internet-dra...@ietf.org
Objet: New Version Notification for 
draft-many-dnsop-dns-isolated-networks-00.txt
Date: 8 octobre 2023 à 15:16:10 HAE
À: "Marc Blanchet" 

A new version of Internet-Draft draft-many-dnsop-dns-isolated-networks-00.txt
has been successfully submitted by Marc Blanchet and posted to the
IETF repository.

Name: draft-many-dnsop-dns-isolated-networks
Revision: 00
Title:Domain Name System in Mostly Isolated Networks
Date: 2023-10-08
Group:Individual Submission
Pages:7
URL:  
https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.txt<https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.txt>
Status:   
https://datatracker.ietf.org/doc/draft-many-dnsop-dns-isolated-networks/<https://datatracker.ietf.org/doc/draft-many-dnsop-dns-isolated-networks/>
HTML: 
https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.html<https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.html>
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-many-dnsop-dns-isolated-networks<https://datatracker.ietf.org/doc/html/draft-many-dnsop-dns-isolated-networks>


Abstract:

  This document lists operational methods to enable local DNS name
  resolving on an isolated network, where that network have
  intermittent reachability to Internet and/or have very long delays,
  disabling the real-time query and response flow to the authoritative
  name servers on Internet.



The IETF Secretariat



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

[DNSOP] Fwd: New Version Notification for draft-many-dnsop-dns-isolated-networks-00.txt

[Marc Blanchet]

Hello,
 The primary use case of this draft is the deployment of naming infrastructure 
on celestial bodies networks, but could be applied for other use cases. 

Would love to get people reviews and comments.

Marc.

> Début du message transféré :
> 
> De: internet-dra...@ietf.org
> Objet: New Version Notification for 
> draft-many-dnsop-dns-isolated-networks-00.txt
> Date: 8 octobre 2023 à 15:16:10 HAE
> À: "Marc Blanchet" 
> 
> A new version of Internet-Draft draft-many-dnsop-dns-isolated-networks-00.txt
> has been successfully submitted by Marc Blanchet and posted to the
> IETF repository.
> 
> Name: draft-many-dnsop-dns-isolated-networks
> Revision: 00
> Title:Domain Name System in Mostly Isolated Networks
> Date: 2023-10-08
> Group:Individual Submission
> Pages:7
> URL:  
> https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.txt
> Status:   
> https://datatracker.ietf.org/doc/draft-many-dnsop-dns-isolated-networks/
> HTML: 
> https://www.ietf.org/archive/id/draft-many-dnsop-dns-isolated-networks-00.html
> HTMLized: 
> https://datatracker.ietf.org/doc/html/draft-many-dnsop-dns-isolated-networks
> 
> 
> Abstract:
> 
>   This document lists operational methods to enable local DNS name
>   resolving on an isolated network, where that network have
>   intermittent reachability to Internet and/or have very long delays,
>   disabling the real-time query and response flow to the authoritative
>   name servers on Internet.
> 
> 
> 
> The IETF Secretariat
> 
> 

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

Re: [DNSOP] Fwd: New Version Notification for draft-peltan-edns-presentation-format-01.txt

[Ben Schwartz]

I have reviewed this draft.  It seems potentially useful and like a reasonable 
attempt to define a solution.

I would like to see a unified rule connecting the text and JSON 
representations, rather than explicitly defining new formats for each key (and 
in some cases even changing the key names, e.g. NSID vs. NSIDHEX).  For 
example, some options could be defined as having "list" type output, and then 
we could define generically how list values are represented in JSON and text.  
Similarly for numbers, strings, etc.  Alternatively, the JSON format could be 
defined first, and the text format could be defined via an algorithm that acts 
generically on the JSON values.

I think it's worth taking a close look at the existing commonly used 
presentation formats before defining a new one.  For example, it might be 
worthwhile to standardize a text representation that is closer to the current 
"dig" output, for the sake of compatibility with existing systems.

--Ben Schwartz

From: DNSOP  on behalf of libor.peltan 

Sent: Wednesday, May 31, 2023 4:33 AM
To: dnsop 
Subject: [DNSOP] Fwd: New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Hi dsnop, we'd like to turn your attention again to our draft https: //www. 
ietf. org/archive/id/draft-peltan-edns-presentation-format-01. html We believe 
this document shall fill a missing gap in specifications, and help 
interoperability of DNS
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd

Hi dsnop,

we'd like to turn your attention again to our draft 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html>

We believe this document shall fill a missing gap in specifications, and help 
interoperability of DNS tools. Therefore, we think it'd make sense if this 
document once becomes a dnsop-homed RFC.

We'd appreciate your feedback and comments.

Update from -00: added Guidelines for Future EDNS(0) Options (thanks to Pieter 
Lexis); nitpicks.

Thank you!

Libor and Tom


 Přeposlaná zpráva 
Předmět:New Version Notification for 
draft-peltan-edns-presentation-format-01.txt
Datum:  Wed, 31 May 2023 01:30:33 -0700
Od: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
Komu:   Libor Peltan <mailto:libor.pel...@nic.cz>, Tom 
Carpay <mailto:tomcar...@gmail.com>



A new version of I-D, draft-peltan-edns-presentation-format-01.txt
has been successfully submitted by Libor Peltan and posted to the
IETF repository.

Name: draft-peltan-edns-presentation-format
Revision: 01
Title: EDNS Presentation and JSON Format
Document date: 2023-05-31
Group: Individual Submission
Pages: 20
URL: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt<https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt>
Status: 
https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/<https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/>
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format<https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format>
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01<https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01>

Abstract:
This document describes textual and JSON representation format of
EDNS option. It also modifies the escaping rules of JSON
representation of DNS messages, previously defined in RFC8427.



The IETF Secretariat


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

Re: [DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-13.txt

[Tim Wicinski]

Peter

On Mon, Jul 17, 2023 at 3:37 AM Peter van Dijk 
wrote:

> On Wed, 2023-07-05 at 18:51 -0400, Tim Wicinski wrote:
>
> All
>
> The authors of draft-ietf-dnsop-avoid-fragmentation worked with different
> implementers to expand upon the index of Known Implementations, and what
> they implement specifically.
>
> The chairs would like to have a one week follow up Working Group Last Call
> comment period. We are looking for substantive comments regarding the
> changes made, and if they are enough to address concerns raised.
>
>
> As Vladimir also said in his dnsdir review, this document is in way better
> shape than it was.
>
> I do see one obstacle.
>
> In section 3.1, the draft says:
>
> > 2. UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF)
> bit" [RFC0791 ] on IPv4.
>
> Then in Appendix D (Known Implementations), all implementations have
> indicated they do *not* set the DF bit. It seems wrong to RECOMMEND
> something, especially in a document targeted for BCP, that nobody is doing.
>
>
This is a good point, and something we need to address.
I've made a note in the chairs slides for tomorrow, and will talk to the
authors.



This comment period will end Wednesday July 12, 2023.   If there
> are substantive comments raised, we can address these during the meeting.
>
> A friendly request: please indicate Last Calls in the Subject! I missed
> this one until now.
>
>
>
Yes and this is my fault.  Apologies.   I am chastised.

Tim

Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-13.txt

[Peter van Dijk]

On Wed, 2023-07-05 at 18:51 -0400, Tim Wicinski wrote:
> All
> 
> The authors of draft-ietf-dnsop-avoid-fragmentation worked with
> different implementers to expand upon the index of Known
> Implementations, and what they implement specifically. 
> 
> The chairs would like to have a one week follow up Working Group Last
> Call comment period. We are looking for substantive comments regarding
> the changes made, and if they are enough to address concerns raised.  

As Vladimir also said in his dnsdir review, this document is in way
better shape than it was.

I do see one obstacle.

In section 3.1, the draft says:

> 2. UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF)
bit" [RFC0791] on IPv4.

Then in Appendix D (Known Implementations), all implementations have
indicated they do *not* set the DF bit. It seems wrong to RECOMMEND
something, especially in a document targeted for BCP, that nobody is
doing.

> This comment period will end Wednesday July 12, 2023.   If there
> are substantive comments raised, we can address these during the
> meeting.
> 
A friendly request: please indicate Last Calls in the Subject! I missed
this one until now.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-avoid-fragmentation-13.txt

[Tim Wicinski]

All

The authors of draft-ietf-dnsop-avoid-fragmentation worked with different
implementers to expand upon the index of Known Implementations, and what
they implement specifically.

The chairs would like to have a one week follow up Working Group Last Call
comment period. We are looking for substantive comments regarding the
changes made, and if they are enough to address concerns raised.

This comment period will end Wednesday July 12, 2023.   If there
are substantive comments raised, we can address these during the meeting.

thanks
tim


-- Forwarded message -
From: 
Date: Wed, Jul 5, 2023 at 3:47 AM
Subject: New Version Notification -
draft-ietf-dnsop-avoid-fragmentation-13.txt
To: , , , <
war...@kumari.net>



A new version (-13) has been submitted for
draft-ietf-dnsop-avoid-fragmentation:
https://www.ietf.org/archive/id/draft-ietf-dnsop-avoid-fragmentation-13.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/

Diff from previous version:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-avoid-fragmentation-13

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

[DNSOP] Fwd: New Version Notification for draft-peltan-edns-presentation-format-01.txt

[libor.peltan]

Hi dsnop,

we'd like to turn your attention again to our draft 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.html


We believe this document shall fill a missing gap in specifications, and 
help interoperability of DNS tools. Therefore, we think it'd make sense 
if this document once becomes a dnsop-homed RFC.


We'd appreciate your feedback and comments.

Update from -00: added Guidelines for Future EDNS(0) Options (thanks to 
Pieter Lexis); nitpicks.


Thank you!

Libor and Tom



 Přeposlaná zpráva 
Předmět: 	New Version Notification for 
draft-peltan-edns-presentation-format-01.txt

Datum:  Wed, 31 May 2023 01:30:33 -0700
Od: internet-dra...@ietf.org
Komu:   Libor Peltan , Tom Carpay 




A new version of I-D, draft-peltan-edns-presentation-format-01.txt
has been successfully submitted by Libor Peltan and posted to the
IETF repository.

Name: draft-peltan-edns-presentation-format
Revision: 01
Title: EDNS Presentation and JSON Format
Document date: 2023-05-31
Group: Individual Submission
Pages: 20
URL: 
https://www.ietf.org/archive/id/draft-peltan-edns-presentation-format-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-peltan-edns-presentation-format/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-peltan-edns-presentation-format
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-peltan-edns-presentation-format-01


Abstract:
This document describes textual and JSON representation format of
EDNS option. It also modifies the escaping rules of JSON
representation of DNS messages, previously defined in RFC8427.



The IETF Secretariat

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

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-cds-consistency-03.txt

[Peter Thomassen]

Dear DNSOP,

This revision of "Consistency for CDS/CDNSKEY and CSYNC is Mandatory" has the 
following changes:

- Advise to attempt retries to resolve inconsistencies
- Added that checking C* consistency also significantly limits impact from 
nameserver hijacking


I've been pondering a related issue, but have omitted it from the draft right 
now. The question is (from the perspective of a parent, such as registry):

--> When ingesting a CSYNC record and subsequently setting out to update the NS 
RRset, should you be checking that any new NS hostnames don't break the existing 
DNSSEC setup?

For example, it can happen that the zone served by new nameserver does not have 
the DNSKEY or RRSIG records as required by the DS RRset (e.g., wrong algorithm, 
or no matching key tag). It could also happen that the new nameserver does not 
advertise any of the other nameserver's DNSKEYs, so that DNSKEYs from the new 
nameserver and RRSIGs from an existing one are inconsistent. Depending what's 
retrieved and cached from which nameserver, this can lead to validation 
failures.

There are two moving pieces, namely the delegation and the DS RRset. Changing 
either of them has similar implications.

For DS updates, we have RFC 7344 Section 4.1: "MUST NOT break the current delegation 
if applied to DS RRset". So, when processing CDS/CDNSKEY records, one is supposed to 
check such things.

Is it an omission that RFC 7477 (CSYNC) has no such acceptance rules? If so, 
should they be added to this draft?

Practically, one could say something like "When processing CSYNC, run the same 
checks on the combined target configuration as when processing CDS/CDNSKEY."

(Note that the CSYNC spec requires the use of DNSSEC; it would be a little 
weird if it could be used to break it ...)


Thanks,
Peter


 Forwarded Message 
Subject: New Version Notification for 
draft-thomassen-dnsop-cds-consistency-03.txt
Date: Sat, 04 Mar 2023 11:58:16 -0800
From: internet-dra...@ietf.org
To: Peter Thomassen 


A new version of I-D, draft-thomassen-dnsop-cds-consistency-03.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:   draft-thomassen-dnsop-cds-consistency
Revision:   03
Title:  Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Document date:  2023-03-04
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-cds-consistency-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/
Html:   
https://www.ietf.org/archive/id/draft-thomassen-dnsop-cds-consistency-03.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-cds-consistency
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-thomassen-dnsop-cds-consistency-03

Abstract:
   Maintenance of DNS delegations requires occasional changes of the DS
   and NS record sets on the parent side of the delegation.  [RFC7344]
   automates this for DS records by having the child publish CDS and/or
   CDNSKEY records which hold the prospective DS parameters.  Similarly,
   CSYNC records indicate a desired update of the delegation's NS
   records [RFC7477].  Parent-side entities (e.g.  Registries,
   Registrars) typically discover these records by periodically querying
   them from the child ("polling"), before using them to update the
   delegation's parameters.

   This document specifies that if polling is used, parent-side entities
   MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records
   are consistent across the child's authoritative nameservers, before
   taking any action based on these records.

  



The IETF Secretariat


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

[DNSOP] Fwd: New Version Notification for draft-bellis-dnsop-qdcount-is-one-00.txt

[Ray Bellis]

 Forwarded Message 
Subject: New Version Notification for 
draft-bellis-dnsop-qdcount-is-one-00.txt

Date: Fri, 17 Feb 2023 08:12:18 -0800
From: internet-dra...@ietf.org
To: Joe Abley , Ray Bellis 


A new version of I-D, draft-bellis-dnsop-qdcount-is-one-00.txt
has been successfully submitted by Ray Bellis and posted to the
IETF repository.

Name:   draft-bellis-dnsop-qdcount-is-one
Revision:   00
Title:  In the DNS, QDCOUNT is (usually) One
Document date:  2023-02-17
Group:  Individual Submission
Pages:  6
URL: 
https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-bellis-dnsop-qdcount-is-one/
Html: 
https://www.ietf.org/archive/id/draft-bellis-dnsop-qdcount-is-one-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-bellis-dnsop-qdcount-is-one



Abstract:
   This document clarifies the allowable values of the QDCOUNT parameter
   in DNS messages with OPCODE = 0 (QUERY) and specifies the required
   behaviour when values that are not allowed are encountered.




The IETF Secretariat


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

Re: [DNSOP] Fwd: New Version Notification for draft-cuiling-dnsop-sm2-alg-02.txt

[zhangcuiling]

I'd like to learn about ISE first.
Thanks a lot for your advice.

Best regards,

Cathy
 
> > Dear dnsop,
> >
> > According to the comment, I modified the draft. There are two major changes.
> >
> > 1. Modify the description of SM3 DS records ( Section 2 )
> > In section 2, the length of digest is listed as a difference between 
> > SHA-256 and SM3,
> > but in reality the length of both algorithms is 32 bytes. [Corrected]
>  
> Note that this document should probably proceed via the Independent
> Stream (ISE), similar to the proposed solution for the GOST document:
>  
>   See 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ballot/#draft-ietf-dnsop-rfc5933-bis_roman-danyliw
>  
> Paul
 
 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-cuiling-dnsop-sm2-alg-02.txt

[Tim Wicinski]

(chairs hat on)

Paul is correct.

Also, I feel we ("we" being the chairs + Overlord Warren + IESG folks)
should write some nice simple text to explain this
to authors in the future.

tim

On Thu, Jan 5, 2023 at 1:42 PM Paul Wouters  wrote:

> On Thu, 5 Jan 2023, zhangcuiling wrote:
>
> > Dear dnsop,
> >
> > According to the comment, I modified the draft. There are two major
> changes.
> >
> > 1. Modify the description of SM3 DS records ( Section 2 )
> > In section 2, the length of digest is listed as a difference between
> SHA-256 and SM3,
> > but in reality the length of both algorithms is 32 bytes. [Corrected]
>
> Note that this document should probably proceed via the Independent
> Stream (ISE), similar to the proposed solution for the GOST document:
>
>   See
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ballot/#draft-ietf-dnsop-rfc5933-bis_roman-danyliw
>
> Paul
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-cuiling-dnsop-sm2-alg-02.txt

[Paul Wouters]

On Thu, 5 Jan 2023, zhangcuiling wrote:


Dear dnsop,

According to the comment, I modified the draft. There are two major changes.

1. Modify the description of SM3 DS records ( Section 2 )
In section 2, the length of digest is listed as a difference between SHA-256 
and SM3,
but in reality the length of both algorithms is 32 bytes. [Corrected]


Note that this document should probably proceed via the Independent
Stream (ISE), similar to the proposed solution for the GOST document:

 See 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/ballot/#draft-ietf-dnsop-rfc5933-bis_roman-danyliw

Paul

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

[DNSOP] Fwd: New Version Notification for draft-cuiling-dnsop-sm2-alg-02.txt

[zhangcuiling]

Dear dnsop,

According to the comment, I modified the draft. There are two major changes.

1. Modify the description of SM3 DS records ( Section 2 )
In section 2, the length of digest is listed as a difference between SHA-256 
and SM3,
but in reality the length of both algorithms is 32 bytes. [Corrected]

2. Add an example zone as an appendix
Provide a full zone that can be loaded by named. It shows the main changes
in a zonefile when using SM2 Digital Signature Algorithm.

Any comments and suggestion will be appreciated.

Best regards,

Cathy Zhang

1/5/2023
 
> A new version of I-D, draft-cuiling-dnsop-sm2-alg-02.txt
> has been successfully submitted by Cuiling Zhang and posted to the
> IETF repository.
>  
> Name: draft-cuiling-dnsop-sm2-alg
> Revision: 02
> Title: SM2 Digital Signature Algorithm for DNSSEC
> Document date: 2023-01-05
> Group: Individual Submission
> Pages: 8
> URL:
> https://www.ietf.org/archive/id/draft-cuiling-dnsop-sm2-alg-02.txt
> Status: https://datatracker.ietf.org/doc/draft-cuiling-dnsop-sm2-alg/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-cuiling-dnsop-sm2-alg
> Diff:   
> https://author-tools.ietf.org/iddiff?url2=draft-cuiling-dnsop-sm2-alg-02
>  
> Abstract:
> This document describes how to specify SM2 Digital Signature
> Algorithm keys and signatures in DNS Security (DNSSEC). It lists
> the curve and uses SM3 as hash algorithm for signatures.
>  
>   
>
>  
>  
> The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-momoka-v6ops-ipv6-only-resolver-00.txt

[Momoka Yamamoto]

Hello,

I have submitted an informational draft that describes resolvers performing
IPv4 to IPv6 translation to send queries to IPv4-only authoritative servers.
We thought it would be beneficial to document that we can operate a
resolver with only an IPv6 address if we utilize the NAT64.
Despite that it is stated in BCP91 [RFC3901], "every recursive name server
SHOULD be either IPv4-only or dual stack."

Since this is more related to IPv6/IPv4 translation I have submitted the
draft to the v6ops wg,
but because this is DNS related I would very much appreciate it if I could
have comments from the dnsop list as well.

Momoka. Y

-- Forwarded message -
From: 
Date: Thu, Oct 6, 2022 at 2:17 AM
Subject: New Version Notification for
draft-momoka-v6ops-ipv6-only-resolver-00.txt
To: Momoka Yamamoto , Toyota Yasunobu <
yasn...@sfc.wide.ad.jp>



A new version of I-D, draft-momoka-v6ops-ipv6-only-resolver-00.txt
has been successfully submitted by Momoka Yamamoto and posted to the
IETF repository.

Name:   draft-momoka-v6ops-ipv6-only-resolver
Revision:   00
Title:  IPv6 only iterative resolver utilising NAT64
Document date:  2022-10-05
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.txt
Status:
https://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
Html:
https://www.ietf.org/archive/id/draft-momoka-v6ops-ipv6-only-resolver-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-momoka-v6ops-ipv6-only-resolver


Abstract:
   By performing IPv4 to IPv6 translation, IPv6-only iterative resolvers
   can operate in an IPv6-only environment.  When a specific DNS zone is
   only served by an IPv4-only authoritative server, the iterative
   resolver will translate the IPv4 address to IPv6 to access the
   authoritative server's IPv4 address via NAT64.  This mechanism allows
   IPv6-only iterative resolvers to initiate communications to IPv4-only
   authoritative servers.




The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-cds-consistency-01.txt

[Peter Thomassen]

Dear DNSOP,

This revision incorporates the feedback from IETF 114, specifically that the 
CDS/CDNSKEY consistency check should be tolerant towards servers that don't 
serve these records or that are unresponsive.

It occurred to me that the same (and in a way, worse) problem exists with 
CSYNC. I therefore extended the draft so that it covers both CDS/CDNSKEY and 
CSYNC processing, spelled out in dedicated sections.

To clarify the scope of the problem, I also added a "Failure Scenarios" section 
that describes what can happen if consistency is not ensured.

Without some kind of consistency check, it's rather dangerous to run a 
multi-homed DNSSEC setup or to do a provider change for a secure delegation. 
(It's just not safe enough against accidents.) I thus think we should make 
these implications widely known, before more child scanning is deployed in 
unsafe ways.

I'm looking forward to your feedback.

Thanks,
Peter


 Forwarded Message 
Subject: New Version Notification for 
draft-thomassen-dnsop-cds-consistency-01.txt
Date: Wed, 14 Sep 2022 17:44:59 -0700
From: internet-dra...@ietf.org
To: Peter Thomassen 


A new version of I-D, draft-thomassen-dnsop-cds-consistency-01.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:   draft-thomassen-dnsop-cds-consistency
Revision:   01
Title:  Consistency for CDS/CDNSKEY and CSYNC is Mandatory
Document date:  2022-09-15
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-cds-consistency-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/
Html:   
https://www.ietf.org/archive/id/draft-thomassen-dnsop-cds-consistency-01.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-cds-consistency
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-thomassen-dnsop-cds-consistency-01

Abstract:
   Maintenance of DNS delegations requires occasional changes of the DS
   and NS record sets on the parent side of the delegation.  [RFC7344]
   automates this for DS records by having the child publish CDS and/or
   CDNSKEY records which hold the prospective DS parameters.  Similarly,
   CSYNC records indicate a desired update of the delegation's NS
   records [RFC7477].  Parent-side entities (e.g.  Registries,
   Registrars) typically discover these records by periodically querying
   them from the child ("polling"), before using them to update the
   delegation's parameters.

   This document specifies that if polling is used, parent-side entities
   MUST ensure that updates triggered via CDS/CDNSKEY and CSYNC records
   are consistent across the child's authoritative nameservers, before
   taking any action based on these records.

  



The IETF Secretariat


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

Re: [DNSOP] Fwd: New Version Notification for draft-cuiling-dnsop-sm2-alg-01.txt

[zhangcuiling]

Hi Nils,
 
Thanks for the comment.

>Hi Cathy,
>
>are there any implementations of this available? 

Unfortunately, as far as I know, there is no such implementation yet.
Of course it's a good idea to start real coding work.
We'd like to support the new algorithm in:
* DNS sevice,
* DNS server software,
* DNS tools,
* at least a prototype system for test.
It depends.
 
And because Openssl has supported SM2/SM3 since version 1.1.1,
It's convenient to have a try for people who are interested in.
 
I think the protocol and the implementation are like two feet.
You have to decide to lift which one first when walking.
Besides introducing the format of PUBKEY, SIGNATURE, DIGEST of
SM2/SM3 in DNS RR, another motivation to submit such a draft is to
apply new algorithm numbers to avoid confliction in advance,
although there are so many numbers available for new algorithms.
 
If there is any implementation that supports SM2/SM3 algorithm,
I'll tell you as soon as I know. 

>
>In Sec. 2, it draft says
>
>> The implementation of SM3 in DNSSEC follows the
>>   implementation of SHA-256 as specified in RFC 4509[RFC4509] except
>>   that the underlying algorithm is SM3, the digest value is 32 bytes
>>   long, and the digest type code is 17 [to be determined].
>
>RFC 4509 states that SHA-256 has 32 byte digest length, so the "except"
>above is a bit misleading. 

You're right. Thanks for the correction. I should delete the following words.
"the digest value is 32 bytes long, "


>While the digest type code is to be
>determined, it should be 6 to be consistent with the rest of the draft. 

6 is for new digest algorithm while 17 is for new signature algorithm.
The draft applies two number for different usage.

Best regards,

Cahty Zhang

>
>Best,
>Nils
>
>On Wed, 2022-08-10 at 16:55 +0800, zhangcuiling wrote:
>> Dear dnsop,
>>
>> According to Paul's comment, I modified the draft. There are two
>> major changes.
>>
>> 1. Replace a reference document with a free one.
>> In the former version, the draft referenced an ISO standard
>> [ISO/IEC14888-3:2018] that is not freely available, so I replace it
>> with another one.
>> And additionally, I noticed that there is a RFC which introduces SM
>> Cipher Suites for TLS 1.3 [RFC8998].
>>
>> 2. Add a few words to describe why it's reasonable to introduce
>> another ECC-based algorithm.
>> Explain the differences between SM2 and ECDSA from the point of view
>> of the curve it uses and the process.
>>
>> Any comments and suggestion will be appreciated.
>>
>> Best regards,
>>
>> Cathy Zhang
>>
>> 8/10/2022
>>
>> > A new version of I-D, draft-cuiling-dnsop-sm2-alg-01.txt
>> > has been successfully submitted by Cuiling Zhang and posted to the
>> > IETF repository.
>> > 
>> > Name:  draft-cuiling-dnsop-sm2-alg
>> > Revision:  01
>> > Title: SM2 Digital Signature Algorithm for DNSSEC
>> > Document date: 2022-07-27
>> > Group: Individual Submission
>> > Pages: 6
>> > URL:   
>> https://www.ietf.org/archive/id/draft-cuiling-dnsop-sm2-alg-01.txt
>> > Status:
>> https://datatracker.ietf.org/doc/draft-cuiling-dnsop-sm2-alg/
>> > Htmlized:  
>> https://datatracker.ietf.org/doc/html/draft-cuiling-dnsop-sm2-alg
>> > Diff:  
>> https://www.ietf.org/rfcdiff?url2=draft-cuiling-dnsop-sm2-alg-01
>> > 
>> > Abstract:
>> >   This document describes how to specify SM2 Digital Signature
>> >   Algorithm keys and signatures in DNS Security (DNSSEC). It lists
>> >   the curve and uses SM3 as hash algorithm for signatures.
>> > 
>> >   
>> 
>> > 
>> > 
>> > The IETF Secretariat
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>--
>deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany
>
>Vorstandsvorsitz: Nils Wisiol
>Registergericht: AG Berlin (Charlottenburg) VR 37525
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-cuiling-dnsop-sm2-alg-01.txt

[Nils Wisiol]

Hi Cathy,

are there any implementations of this available?

In Sec. 2, it draft says

> The implementation of SM3 in DNSSEC follows the
>   implementation of SHA-256 as specified in RFC 4509[RFC4509] except
>   that the underlying algorithm is SM3, the digest value is 32 bytes
>   long, and the digest type code is 17 [to be determined].

RFC 4509 states that SHA-256 has 32 byte digest length, so the "except"
above is a bit misleading. While the digest type code is to be
determined, it should be 6 to be consistent with the rest of the draft.

Best,
Nils

On Wed, 2022-08-10 at 16:55 +0800, zhangcuiling wrote:
> Dear dnsop,
> 
> According to Paul's comment, I modified the draft. There are two
> major changes.
> 
> 1. Replace a reference document with a free one.
> In the former version, the draft referenced an ISO standard
> [ISO/IEC14888-3:2018] that is not freely available, so I replace it
> with another one.
> And additionally, I noticed that there is a RFC which introduces SM
> Cipher Suites for TLS 1.3 [RFC8998].
> 
> 2. Add a few words to describe why it's reasonable to introduce
> another ECC-based algorithm.
> Explain the differences between SM2 and ECDSA from the point of view
> of the curve it uses and the process.
> 
> Any comments and suggestion will be appreciated.
> 
> Best regards,
> 
> Cathy Zhang
> 
> 8/10/2022
> 
> > A new version of I-D, draft-cuiling-dnsop-sm2-alg-01.txt
> > has been successfully submitted by Cuiling Zhang and posted to the
> > IETF repository.
> >  
> > Name:   draft-cuiling-dnsop-sm2-alg
> > Revision:   01
> > Title:  SM2 Digital Signature Algorithm for DNSSEC
> > Document date:  2022-07-27
> > Group:  Individual Submission
> > Pages:  6
> > URL:
> https://www.ietf.org/archive/id/draft-cuiling-dnsop-sm2-alg-01.txt
> > Status: 
> https://datatracker.ietf.org/doc/draft-cuiling-dnsop-sm2-alg/
> > Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-cuiling-dnsop-sm2-alg
> > Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-cuiling-dnsop-sm2-alg-01
> >  
> > Abstract:
> >   This document describes how to specify SM2 Digital Signature
> >   Algorithm keys and signatures in DNS Security (DNSSEC). It lists
> >   the curve and uses SM3 as hash algorithm for signatures.
> >  
> >
>  
> >  
> >  
> > The IETF Secretariat
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
deSEC e.V. · Kyffhäuserstr. 5 · 10781 Berlin · Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525


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

[DNSOP] Fwd: New Version Notification for draft-cuiling-dnsop-sm2-alg-01.txt

[zhangcuiling]

Dear dnsop,

According to Paul's comment, I modified the draft. There are two major changes.

1. Replace a reference document with a free one.
In the former version, the draft referenced an ISO standard 
[ISO/IEC14888-3:2018] that is not freely available, so I replace it with 
another one.
And additionally, I noticed that there is a RFC which introduces SM Cipher 
Suites for TLS 1.3 [RFC8998].

2. Add a few words to describe why it's reasonable to introduce another 
ECC-based algorithm.
Explain the differences between SM2 and ECDSA from the point of view of the 
curve it uses and the process.

Any comments and suggestion will be appreciated.

Best regards,

Cathy Zhang

8/10/2022

> A new version of I-D, draft-cuiling-dnsop-sm2-alg-01.txt
> has been successfully submitted by Cuiling Zhang and posted to the
> IETF repository.
>  
> Name: draft-cuiling-dnsop-sm2-alg
> Revision: 01
> Title: SM2 Digital Signature Algorithm for DNSSEC
> Document date: 2022-07-27
> Group: Individual Submission
> Pages: 6
> URL:
> https://www.ietf.org/archive/id/draft-cuiling-dnsop-sm2-alg-01.txt
> Status: https://datatracker.ietf.org/doc/draft-cuiling-dnsop-sm2-alg/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-cuiling-dnsop-sm2-alg
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-cuiling-dnsop-sm2-alg-01
>  
> Abstract:
>   This document describes how to specify SM2 Digital Signature
>   Algorithm keys and signatures in DNS Security (DNSSEC). It lists
>   the curve and uses SM3 as hash algorithm for signatures.
>  
>   
>
>  
>  
> The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-rfc5933-bis-09.txt

[Dmitry Belyavsky]

Dear colleagues,

Here is the updated version of the
"Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records
for DNSSEC"
IETF draft.

We have a new coauthor, Boris Makarenko, who kindly agreed to continue the
development process.

-- Forwarded message -
From: 
Date: Thu, Jul 28, 2022 at 2:10 PM
Subject: New Version Notification for draft-ietf-dnsop-rfc5933-bis-09.txt
To: Boris Makarenko , Dmitry Belyavskiy <
beld...@gmail.com>, Vasily Dolmatov 



A new version of I-D, draft-ietf-dnsop-rfc5933-bis-09.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:   draft-ietf-dnsop-rfc5933-bis
Revision:   09
Title:  Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG
Resource Records for DNSSEC
Document date:  2022-07-28
Group:  dnsop
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-09.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-09

Abstract:
   This document describes how to produce digital signatures and hash
   functions using the GOST R 34.10-2012 and GOST R 34.11-2012
   algorithms for DNSKEY, RRSIG, and DS resource records, for use in the
   Domain Name System Security Extensions (DNSSEC).

   This document obsoletes RFC 5933 and updates RFC 8624.




The IETF Secretariat




-- 
SY, Dmitry Belyavsky
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-rfc5933-bis-08.txt

[Dmitry Belyavsky]

Dear colleagues,

The updated version of RFC 5933-bis draft is uploaded.

The updated version partially resolves the issues raised by Michael StJohns
in his thorough review.

I hope there will be more interest in the updated version of the draft than
it was during the previous WGLC.

As I'm not subscribed to dnsop@ nowadays, I kindly ask not to remove me
from the recipients list. Many thanks in advance!

-- Forwarded message -
From: 
Date: Sun, Jul 10, 2022 at 6:06 PM
Subject: New Version Notification for draft-ietf-dnsop-rfc5933-bis-08.txt
To: Dmitry Belyavskiy , Vasily Dolmatov <
vdolma...@gmail.com>



A new version of I-D, draft-ietf-dnsop-rfc5933-bis-08.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:   draft-ietf-dnsop-rfc5933-bis
Revision:   08
Title:  Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG
Resource Records for DNSSEC
Document date:  2022-07-10
Group:  dnsop
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5933-bis-08.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-08

Abstract:
   This document describes how to produce digital signatures and hash
   functions using the GOST R 34.10-2012 and GOST R 34.11-2012
   algorithms for DNSKEY, RRSIG, and DS resource records, for use in the
   Domain Name System Security Extensions (DNSSEC).

   This document obsoletes RFC 5933 and updates RFC 8624.




The IETF Secretariat




-- 
SY, Dmitry Belyavsky
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-cds-consistency-00.txt

[Peter Thomassen]

Dear DNSOP,

As discussed in 
https://mailarchive.ietf.org/arch/msg/dnsop/nQQsixIT5cXFukBq4Ky67mCniAk/, I 
wrote a short I-D to update RFC 7344 such that CDS/CDNSKEY consistency is 
mandatory across authoritative nameservers. The result is below.

Looking forward to your feedback.

Cheers,
Peter


 Forwarded Message 
Subject: New Version Notification for 
draft-thomassen-dnsop-cds-consistency-00.txt
Date: Sat, 09 Jul 2022 04:36:46 -0700
From: internet-dra...@ietf.org
To: Peter Thomassen 


A new version of I-D, draft-thomassen-dnsop-cds-consistency-00.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:   draft-thomassen-dnsop-cds-consistency
Revision:   00
Title:  Ensuring CDS/CDNSKEY Consistency is Mandatory
Document date:  2022-07-09
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-cds-consistency-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-cds-consistency/
Html:   
https://www.ietf.org/archive/id/draft-thomassen-dnsop-cds-consistency-00.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-cds-consistency


Abstract:
   For maintaining DNSSEC Delegation Trust, DS records have to be kept
   up to date.  [RFC7344] automates this by having the child publish CDS
   and/or CDNSKEY records which hold the prospective DS parameters.
   Parent-side entities (e.g.  Registries, Registrars) can use these
   records to update the delegation's DS records.  A common method for
   detecting changes in CDS/CDNSKEY record sets is to query them
   periodically from the child zone ("polling"), as described in
   Section 6.1 of [RFC7344].

   This document specifies that if polling is used, parent-side entities
   MUST ensure that CDS/CDNSKEY record sets are equivalent across all of
   the child's authoritative nameservers, before taking any action based
   on these records.

  



The IETF Secretariat


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

Re: [DNSOP] Fwd: New Version Notification for draft-dwmtwc-dnsop-caching-resolution-failures-00.txt

[Wessels, Duane]

Hi Petr,

I would say one is a subset of the other, but not exactly the same topic.

draft-moura-dnsop-negative-cache-loop focuses relatively narrowly on one type 
of resolution failure: delegations in a loop / cyclic dependency as documented 
in their TusNAME work.

draft-dwmtwc-dnsop-caching-resolution-failures, on the other hand, is intended 
to cover resolution failures much more broadly. Based on our experience, we 
observe abnormal behavior in a number of different situations including 
outages, timeouts, server failures, validation failures, and delegation 
problems.

We plan to present our draft at the next meeting and I assume the other authors 
will as well, so that will be a good chance for the working group to give us 
all feedback.

DW



> On Feb 8, 2022, at 5:28 AM, Petr Špaček  wrote:
> 
> Hello everyone,
> 
> it seems that we now have two drafts about the same topic - this new one and 
> draft-moura-dnsop-negative-cache-loop.
> 
> Perhaps authors could discuss if they are in agreement and could pick one?
> 
> Petr Špaček  @  Internet Systems Consortium
> 
> 
> 
> On 14. 01. 22 19:14, Wessels, Duane wrote:
>> Dear DNSOP,
>> In light of some recent events and research, we feel that it could be 
>> beneficial to strengthen the requirements around negative caching of DNS 
>> resolution failures. Please see the recently submitted Internet Draft 
>> referenced below and let us know if you have any feedback.
>> DW
>>> Begin forwarded message:
>>> 
>>> *From: *mailto:internet-dra...@ietf.org>>
>>> *Subject: **[EXTERNAL] New Version Notification for 
>>> draft-dwmtwc-dnsop-caching-resolution-failures-00.txt*
>>> *Date: *January 13, 2022 at 1:28:00 PM PST
>>> *To: *Duane Wessels mailto:dwess...@verisign.com>>, 
>>> Matthew Thomas mailto:mtho...@verisign.com>>, 
>>> William Carroll mailto:wicarr...@verisign.com>>
>>> 
>>> A new version of I-D, draft-dwmtwc-dnsop-caching-resolution-failures-00.txt
>>> has been successfully submitted by William Carroll and posted to the
>>> IETF repository.
>>> 
>>> Name:draft-dwmtwc-dnsop-caching-resolution-failures
>>> Revision:00
>>> Title:Negative Caching of DNS Resolution Failures
>>> Document date:2022-01-13
>>> Group:Individual Submission
>>> Pages:13
>>> URL: 
>>> https://secure-web.cisco.com/1-PFLv-gJPKY7IUv53FHemsD97LSSdToCXsQHAguzJmIyVR8DlgbIUfK3NQBXH-5zgoS4DQIIvAT9SMf0y632bk-kgt0veCCWPt9eqKvdmUM_8bz-jZwYAtW9vzG8Yle7Gp7sv_jeafkAwZw5L2kCkJgy4hfNVxUERJJyCxnWI88uVj_yjKi5NiJgO5ANYPWUfYKdg_SnWCnWUDLuwAgLHaD476ZKPPsK82E0W_s8SJOQoH4OGG9glsNw5_92tWYg/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-dwmtwc-dnsop-caching-resolution-failures-00.txt
>>>  
>>> 
>>> Status: 
>>> https://secure-web.cisco.com/1DyTvZbisHjKnPovlyhjAOtHxDAwKAqB2zXhGz5eE0Ca-1XPZAqQhDEyq-XNf1nKXr9SySf_nEWu5XQkh450f2xF3gmfQKMuLIyBqZqbYTfqZyyMbWrcyG3KqVYjmGV6dL3NSnwTn0iXcgzWvT7mLCzivYnGbpRH23V8z4fqw3ikCCp6NwxyuP8O_ak1u03fM9kH0QYTu_C1vGE3rGAn7dFkT0A4Vk3mRhgnZSlh3vhaJmDWMO1xylYlPvJBQ40Af/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dwmtwc-dnsop-caching-resolution-failures%2F
>>>  
>>> 
>>> Htmlized: 
>>> https://secure-web.cisco.com/1MtdsiBy0XYrTWaww2jsyGmhpR1_l4cfsY2lzwq4M4gkF3VU-omPqy4e66hhbK7hfsy_x0cC1ZTi4VBXdrxpcOJPQgL-NdJ6b_iqYKCiDtAXs-6A60hPQqq4UZ7C7A1iyL29ghpvCZWMAvER26fj-YW4tmLvr5avpsjTGdZZTCIzvskQ9Nn-Degm8WJ03ldm01hMS6gB7ditarcN0g-dAl6zKyLmHKLy-txj3g8mNMsKTuTmkkE7vXFX-YxgBfJel/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dwmtwc-dnsop-caching-resolution-failures
>>>  
>>> 
>>> 
>>> 
>>> Abstract:
>>>   In the DNS, resolvers employ caching to reduce both latency for end
>>>   users and load on authoritative name servers.  The process of
>>>   resolution may result in one of three types of responses: (1) a
>>>   response containing the requested data; (2) a response indicating the
>>>   requested data does not exist; or (3) a non-response due to a

Re: [DNSOP] Fwd: New Version Notification for draft-dwmtwc-dnsop-caching-resolution-failures-00.txt

[Petr Špaček]

Hello everyone,

it seems that we now have two drafts about the same topic - this new one 
and draft-moura-dnsop-negative-cache-loop.


Perhaps authors could discuss if they are in agreement and could pick one?

Petr Špaček  @  Internet Systems Consortium



On 14. 01. 22 19:14, Wessels, Duane wrote:

Dear DNSOP,

In light of some recent events and research, we feel that it could be 
beneficial to strengthen the requirements around negative caching of DNS 
resolution failures. Please see the recently submitted Internet Draft 
referenced below and let us know if you have any feedback.


DW



Begin forwarded message:

*From: *mailto:internet-dra...@ietf.org>>
*Subject: **[EXTERNAL] New Version Notification for 
draft-dwmtwc-dnsop-caching-resolution-failures-00.txt*

*Date: *January 13, 2022 at 1:28:00 PM PST
*To: *Duane Wessels >, Matthew Thomas >, William Carroll 
mailto:wicarr...@verisign.com>>


A new version of I-D, 
draft-dwmtwc-dnsop-caching-resolution-failures-00.txt

has been successfully submitted by William Carroll and posted to the
IETF repository.

Name:draft-dwmtwc-dnsop-caching-resolution-failures
Revision:00
Title:Negative Caching of DNS Resolution Failures
Document date:2022-01-13
Group:Individual Submission
Pages:13
URL: 
https://www.ietf.org/archive/id/draft-dwmtwc-dnsop-caching-resolution-failures-00.txt 

Status: 
https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/ 

Htmlized: 
https://datatracker.ietf.org/doc/html/draft-dwmtwc-dnsop-caching-resolution-failures 




Abstract:
  In the DNS, resolvers employ caching to reduce both latency for end
  users and load on authoritative name servers.  The process of
  resolution may result in one of three types of responses: (1) a
  response containing the requested data; (2) a response indicating the
  requested data does not exist; or (3) a non-response due to a
  resolution failure in which the resolver does not receive any useful
  information regarding the data's existence.  This document concerns
  itself only with the third type.

  RFC 2308 specifies requirements for DNS negative caching.  There,
  caching of type (1) and (2) responses is mandatory and caching of
  type (3) responses is optional.  This document updates RFC 2308 to
  require negative caching for DNS resolution failures.




The IETF Secretariat


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

[DNSOP] Fwd: New Version Notification for draft-dwmtwc-dnsop-caching-resolution-failures-00.txt

[Wessels, Duane]

Dear DNSOP,

In light of some recent events and research, we feel that it could be 
beneficial to strengthen the requirements around negative caching of DNS 
resolution failures. Please see the recently submitted Internet Draft 
referenced below and let us know if you have any feedback.

DW


Begin forwarded message:

From: mailto:internet-dra...@ietf.org>>
Subject: [EXTERNAL] New Version Notification for 
draft-dwmtwc-dnsop-caching-resolution-failures-00.txt
Date: January 13, 2022 at 1:28:00 PM PST
To: Duane Wessels mailto:dwess...@verisign.com>>, 
Matthew Thomas mailto:mtho...@verisign.com>>, William 
Carroll mailto:wicarr...@verisign.com>>

A new version of I-D, draft-dwmtwc-dnsop-caching-resolution-failures-00.txt
has been successfully submitted by William Carroll and posted to the
IETF repository.

Name: draft-dwmtwc-dnsop-caching-resolution-failures
Revision: 00
Title: Negative Caching of DNS Resolution Failures
Document date: 2022-01-13
Group: Individual Submission
Pages: 13
URL:
https://www.ietf.org/archive/id/draft-dwmtwc-dnsop-caching-resolution-failures-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-dwmtwc-dnsop-caching-resolution-failures


Abstract:
  In the DNS, resolvers employ caching to reduce both latency for end
  users and load on authoritative name servers.  The process of
  resolution may result in one of three types of responses: (1) a
  response containing the requested data; (2) a response indicating the
  requested data does not exist; or (3) a non-response due to a
  resolution failure in which the resolver does not receive any useful
  information regarding the data's existence.  This document concerns
  itself only with the third type.

  RFC 2308 specifies requirements for DNS negative caching.  There,
  caching of type (1) and (2) responses is mandatory and caching of
  type (3) responses is optional.  This document updates RFC 2308 to
  require negative caching for DNS resolution failures.




The IETF Secretariat



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

Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Peter Thomassen]

On 11/5/21 1:07 AM, Paul Wouters wrote:

In general, the problem is that we need to make it easier for the DNS
hoster to enable DNSSEC when their customers are non-technical. I think
this draft does properly extend RFC 8078 and even think this document
could deprecate the "Accept after wait" method.


I took a shot at that in -03.


However, I do think it
should still impose a minimum length of publication before accepting,
so that mistakes similar to the recent slack.com outage can be
prevented. So change "accept after wait" to "verify, then accept after
wait".


Sure. The draft currently says in Section 3.2:
| If the above steps succeed without error, the CDS/CDNSKEY records are
| successfully validated, and the Parental Agent can proceed with the
| publication of the DS record set under the precautions described in
| [RFC8078], Section 5.

... and there, it says:
| A parent SHOULD [...] ensure
| that the zone validates correctly if the parent publishes the DS
| record.  A parent zone might also consider sending an email to its
| contact addresses to give the child zone a warning that security will
| be enabled after a certain amount of wait time -- thus allowing a
| child administrator to cancel the request.

I think that from a technical perspective, that covers the policy you're 
proposing.

Or did you really mean to *impose* a minimum delay, as in: it is forbidden to 
deploy more quickly?

Another approach would be to re-state explicitly what's in RFC 8078 Section 5 
(but I don't know if text duplication between RFCs is welcome?).

Best,
Peter

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

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-03.txt

[Peter Thomassen]

Dear DNSOP,

This draft introduces automatic bootstrapping of DNSSEC delegations. The 
previous version has been presented at IETF 112, and the new version 
incorporates the feedback gathered there (and on this list before the meeting).

Changes (taken from Appendix, with additional notes):

- Clarified importance of record cleanup by moving paragraph up.
  # this is Section 4.1

- Pointed out limitations.
  # this is (new) Section 3.4

- Replace [RFC8078] Section 3 with our Section 3.2.
  # It was proposed to deprecate RFC 8078 Section 3.3 ("Accept after Delay"). 
Replacing all of Section 3 is one way of doing this. Of course, we can limit the update 
to Section 3.3.

- Changed _boot label to _dsauth.
  # based on a proposal to switch to _dsbootstrap, but I like _dsauth better :-)

- Removed hashing of Child name components in Signaling Names.
  # as discussed at the meeting

- Editorial changes.

Looking forward to the next steps!

Thanks,
Peter


 Forwarded Message 
Subject: New Version Notification for 
draft-thomassen-dnsop-dnssec-bootstrapping-03.txt
Date: Mon, 29 Nov 2021 15:57:25 -0800
From: internet-dra...@ietf.org
To: Nils Wisiol , Peter Thomassen 


A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-03.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:   draft-thomassen-dnsop-dnssec-bootstrapping
Revision:   03
Title:  Automatic DNSSEC Bootstrapping using Authenticated Signals from 
the Zone's Operator
Document date:  2021-11-29
Group:  Individual Submission
Pages:  14
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-03.txt
Status: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/
Html:   
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-03.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-dnssec-bootstrapping
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-thomassen-dnsop-dnssec-bootstrapping-03

Abstract:
   This document introduces an in-band method for DNS operators to
   publish arbitrary information about the zones they are authoritative
   for, in an authenticated fashion and on a per-zone basis.  The
   mechanism allows managed DNS operators to securely announce DNSSEC
   key parameters for zones under their management, including for zones
   that are not currently securely delegated.

   Whenever DS records are absent for a zone's delegation, this signal
   enables the parent's registry or registrar to cryptographically
   validate the CDS/CDNSKEY records found at the child's apex.  The
   parent can then provision DS records for the delegation without
   resorting to out-of-band validation or weaker types of cross-checks
   such as "Accept after Delay" ([RFC8078]).

   This document updates [RFC8078] and replaces its Section 3 with
   Section 3.2 of this document.

   [ Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.  This document is
   being collaborated on at https://github.com/desec-io/draft-thomassen-
   dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-
   thomassen-dnsop-dnssec-bootstrapping/).  The most recent version of
   the document, open issues, etc. should all be available there.  The
   authors gratefully accept pull requests. ]

  



The IETF Secretariat


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

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Sun, Sep 19, 2021 at 2:42 PM
Subject: New Version Notification for draft-dickson-dnsop-ds-hack-02.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dnsop-ds-hack-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-ds-hack
Revision:   02
Title:  DS Algorithms for Securing NS and Glue
Document date:  2021-09-19
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-ds-hack/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-ds-hack-02

Abstract:
   This Internet Draft proposes a mechanism to encode relevant data for
   NS records on the parental side of a zone cut by encoding them in DS
   records based on a new DNSKEY algorithm.

   Since DS records are signed by the parent, this creates a method for
   validation of the otherwise unsigned delegation records.

   Notably, support for updating DS records in a parent zone is already
   present (by necessity) in the Registry-Registrar-Registrant (RRR)
   provisioning system, EPP.  Thus, no changes to the EPP protocol are
   needed, and no changes to registry database or publication systems
   upstream of the DNS zones published by top level domains (TLDs).

   This NS validation mechanism is beneficial if the name server _names_
   need to be validated prior to use.




The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-glueless-02.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Wed, Sep 22, 2021 at 12:50 AM
Subject: New Version Notification for draft-dickson-dnsop-glueless-02.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dnsop-glueless-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-glueless
Revision:   02
Title:  Operating a Glueless DNS Authority Server
Document date:  2021-09-22
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-glueless/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-glueless
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-glueless-02

Abstract:
   This Internet Draft proposes a method for protecting authority
   servers against MITM and poisoning attacks, using a domain naming
   strategy to not require glue A/ records and use of DNSSEC.

   This technique assumes the use of validating resolvers.

   MITM and poisoning attacks should only be effective/possible against
   unsigned domains.

   However, until all domains are signed, this guidance is relevant, in
   that it can limit the attack surface of unsigned domains.

   This guidance should be combined with [I-D.dickson-dnsop-ds-hack]




The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-dickson-dprive-dnst-00.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Sun, Oct 24, 2021 at 9:13 PM
Subject: New Version Notification for draft-dickson-dprive-dnst-00.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dprive-dnst-00.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dprive-dnst
Revision:   00
Title:  Resource Record for Signaling Transport for DNS to
Authority Servers
Document date:  2021-10-24
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-dnst-00.txt
Status: https://datatracker.ietf.org/doc/draft-dickson-dprive-dnst/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-dnst-00.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-dnst


Abstract:
   This Internet Draft proposes an RRTYPE to signal explicit support for
   transport types for DNS service.  This new RRTYPE is "DNST".  The
   available transports to signal are TCP and UDP on port 53 (DNS), and
   DoT (DNS over TLS) transport using TCP port 853.




The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-dickson-dprive-adot-auth-06.txt

[Brian Dickson]

Dear DPRIVE and DNSOP,
Here is one of the drafts referenced in my presentation(s) on Thursday.
Brian

-- Forwarded message -
From: 
Date: Tue, Nov 9, 2021 at 6:11 PM
Subject: New Version Notification for draft-dickson-dprive-adot-auth-06.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dprive-adot-auth-06.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dprive-adot-auth
Revision:   06
Title:  Authenticated DNS over TLS to Authoritative Servers
Document date:  2021-11-09
Group:  Individual Submission
Pages:  17
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-06.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-06.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-adot-auth
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dprive-adot-auth-06

Abstract:
   This Internet Draft proposes a mechanism for DNS resolvers to
   discover support for TLS transport to authoritative DNS servers, to
   validate this indication of support, and to authenticate the TLS
   certificates involved.

   This requires that the name server _names_ are in a DNSSEC signed
   zone.

   This also requires that the delegation of the zone served is
   protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the
   keys used for discovery of TLS transport support.

   Additional recommendations relate to use of various techniques for
   efficiency and scalability, and new EDNS options to minimize round
   trips and for signaling between clients and resolvers.




The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Paul Wouters]

On Tue, 9 Nov 2021, Peter Thomassen wrote:


 This draft introduces automatic bootstrapping of DNSSEC delegations. It
 uses an in-band method for DNS operators to publish information about the
 zones they host, per-zone and with authentication. With this protocol, DS
 provisioning can happen securely and without delay.


 I've read the draft, and it is an interesting idea. Some thoughts I had:

 - Is it really needed to do hashing? Do we really expect domain names to
    hit the 63 or 255 limit ?


Regarding hitting length limits:

- IPv6 reverse DNS hostnames (under ip6.arpa.) already have length 73.


But would they hit 255 ?


  I wouldn't dare make a prediction about what kind of names could be
  introduced in the next decade (think of underscore labels for TLS
  identities, perhaps with other parameters encoded in front etc.).


Per definition, you can create domain names that are too long to support
_underscore labels on top of them. And yet there we did not use hashing
either?


  I'd rather be conservative on exhausting the available length limits.


There is something to be said for keeping thing simple too, and more
human debuggable. Hashes don't make that easy.


Other technical considerations:

- Not hashing creates semantic collisions.  Practical example from our
  deployment at deSEC:  The list of delegations under dedyn.io is long
  and changes frequently, so we'd probably like to put bootstrapping
  records for children of dedyn.io into a separate zone.
  Without hashing, that zone would be dedyn.io._boot..If we do
  that, then we can't use bootstrapping for dedyn.io itself, because
  dedyn.io._boot. would be an apex name.  This collides with the
  requirement that bootstrapping records MUST NOT occur at the apex
  (where they would signify *that* zone's own DS info).


You can't bootstrap in-baliwick anyway, can you?

Also if your nameserver name is not in a zone protected by DNSSEC,
you cannot use it in this scheme to deploy either I thought?


- This problem generally occurs with public suffixes.  For example,
  when bootstrapping a TLD, you wouldn't be able to create a separate
  bootstrapping zone for its children.  Of course, that's an unlikely
  case, but I think the protocol should be agnostic about that.


You could simply use a different _label for the two cases. I did not
like _boot anyway as it is too generic, so perhaps you could use
_dnssec_bootstrap and _dnssec_hosted_bootstrap or something similar.


- Clear datastructures simplify implementation (in my experience).
  Hashing leads to a very predictable data structure with always two
  labels in front of the underscore label.  Also, that label would be
  an ENT; all records live at the leaves of the tree.  This assumption
  cannot be made when the names are simply concatenated (see above).


ENT's aren't that great :P For example, with query minimalization on
AWS Route53, these have been broken for years. I'd stay away from ENTs.


- When bootstrapping a child with a private parent (e.g. in a corporate
  namespace), hashing the child's immediate ancestor gives a privacy
  benefit even when NSEC walking is allowed (for discovering pending
  bootstrappable names).  (Of course, the benefit is limited, and
  counterarguments similar to the ones against NSEC3 can be made.)


Yeah.


Are there any conceptual downsides of the hashed label that would
outweigh these points?


Yes. Speaking of NSEC3, that is super hard for people to grasp. To us
experts it is obvious, but all the hashes makes a new person who looks
at it pretty confused. I think it would be good in general to try and
make it so that operators can debug DNS issues with the dig command,
without needing advanced tools.


 - _boot seems too generic a name for this. _dsbootstrap would be better
    and cause less clashing


Agreed, tracking here:
https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping/issues/5


Thanks!


 - I would like to see some text on removing the records too once the
    child gained its DS record.


There is text on that in the last paragraph on Section 4.1.  Should it
be expanded or moved to a more promiment place?


I missed that. Perhaps it would be good to give it is own section. We
all know now how bad TXT records at the APEX are now, and anything to
repeat such a thing again would be good.


 - Should it be explicitly noted that in-bailiwick domains are not
    supported?


I think that would be good. Tracking here:
https://github.com/desec-io/draft-thomassen-dnsop-dnssec-bootstrapping/issues/6


Thanks.


 - It puts a constraint of the nameserver being in a zone that is DNSSEC
    enabled. This is currently not required (though very often the case
    anyway)


Yes, prevalence of that is surprisingly high (currently about 25% of
domains in the Tranco 1M toplist).  This protocol would be a reason to
increase that number, as are other protocols (such as parameters for
TLS between resolver and auth, as proposed elsewhere).

Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[John Levine]

It appears that Paul Wouters   said:
>I've read the draft, and it is an interesting idea. Some thoughts I had:
>
>- Is it really needed to do hashing? Do we really expect domain names to
>   hit the 63 or 255 limit ? 

Probably not.  There was also some thought that this makes it harder for
tourists to guess the delegated zone names, not sure if anyone would care.

>- I would like to see some text on removing the records too once the
>   child gained its DS record.

That really needs to be about scaling issues.  If your NS serves three
zones and you leave in the _boot records, who cares.  But there are
NS that serve three million zones and I think we would all like to
avoid long useless NSEC walks.

>- Should it be explicitly noted that in-bailiwick domains are not
>   supported?

Yes, I thought that was in there already.  I did some counts in TLD
files and found that in practice very few 2LDs use in-bailiwick NS.
We should document it but it's not a big deal.

>- It puts a constraint of the nameserver being in a zone that is DNSSEC
>   enabled. This is currently not required (though very often the case
>   anyway)

The point of this is to do a DNSSEC bootstrap that is fully DNSSEC
validated.  If the _boot record doesn't have to be signed, you might
as well just use the CDS from the child server.

R's,
John

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

Re: [DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Paul Wouters]

On Tue, 26 Oct 2021, Peter Thomassen wrote:

This draft introduces automatic bootstrapping of DNSSEC delegations. It uses 
an in-band method for DNS operators to publish information about the zones 
they host, per-zone and with authentication. With this protocol, DS 
provisioning can happen securely and without delay.


I've read the draft, and it is an interesting idea. Some thoughts I had:

- Is it really needed to do hashing? Do we really expect domain names to
  hit the 63 or 255 limit ? 
- _boot seems too generic a name for this. _dsbootstrap would be better

  and cause less clashing
- I would like to see some text on removing the records too once the
  child gained its DS record.
- Should it be explicitly noted that in-bailiwick domains are not
  supported?
- It puts a constraint of the nameserver being in a zone that is DNSSEC
  enabled. This is currently not required (though very often the case
  anyway)

In general, the problem is that we need to make it easier for the DNS
hoster to enable DNSSEC when their customers are non-technical. I think
this draft does properly extend RFC 8078 and even think this document
could deprecate the "Accept after wait" method. However, I do think it
should still impose a minimum length of publication before accepting,
so that mistakes similar to the recent slack.com outage can be
prevented. So change "accept after wait" to "verify, then accept after
wait".

Paul

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

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-02.txt

[Peter Thomassen]

Dear DNSOP and DNSSEC bootstrapping aficionados,

This draft introduces automatic bootstrapping of DNSSEC delegations. It uses an 
in-band method for DNS operators to publish information about the zones they 
host, per-zone and with authentication. With this protocol, DS provisioning can 
happen securely and without delay.

We requested a slot at IETF 112 to present the draft, and it would be great to 
have some discussions about it then. We'd also like to work towards adoption in 
the WG if there is interest.

There are no technical changes from the previous version -01. Updates are 
exclusively on clarity, framing (as an RFC 8078 authentication method instead 
of a separate protocol), and otherwise editorial.

Thanks,
Peter


 Forwarded Message 
Subject: New Version Notification for 
draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
Date: Mon, 25 Oct 2021 16:56:41 -0700
From: internet-dra...@ietf.org
To: Nils Wisiol , Peter Thomassen 


A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:   draft-thomassen-dnsop-dnssec-bootstrapping
Revision:   02
Title:  Automatic DNSSEC Bootstrapping using Authenticated Signals from 
the Zone's Operator
Document date:  2021-10-25
Group:  Individual Submission
Pages:  15
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/
Html:   
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-02.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-dnssec-bootstrapping
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-thomassen-dnsop-dnssec-bootstrapping-02

Abstract:
   This document introduces an in-band method for DNS operators to
   publish arbitrary information about the zones they are authoritative
   for, in an authenticated fashion and on a per-zone basis.  The
   mechanism allows managed DNS operators to securely announce DNSSEC
   key parameters for zones under their management, including for zones
   that are not currently securely delegated.

   Whenever DS records are absent for a zone's delegation, this signal
   enables the parent's registry or registrar to cryptographically
   validate the CDS/CDNSKEY records found at the child's apex.  The
   parent can then provision DS records for the delegation without
   resorting to out-of-band validation or weaker types of cross-checks
   such as "Accept after Delay" ([RFC8078]).

   [ Ed note: Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.  This document is
   being collaborated on at https://github.com/desec-io/draft-thomassen-
   dnsop-dnssec-bootstrapping/ (https://github.com/desec-io/draft-
   thomassen-dnsop-dnssec-bootstrapping/).  The most recent version of
   the document, open issues, etc. should all be available there.  The
   authors gratefully accept pull requests. ]

  



The IETF Secretariat


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

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-glueless-01.txt

[Brian Dickson]

Hi, DNSOP folks,
I have been working on the "unsigned glue record"  problem (and related
"unsigned NS record" problem).

This draft is mostly informational, and does not actually require any
protocol changes.
It might even be worth making a BCP, but I'll leave that up to the WG to
decide.

I think this is relatively widely applicable, even though it was originally
motivated by a problem that needed to be solved within DPRIVE.
(That problem is the subject of a draft I will be posting in DPRIVE, for
those interested.)

I think it's fairly straightforward, but it is difficult to tell without
getting feedback, so please let me know what you think.

Brian Dickson

-- Forwarded message -
From: 
Date: Fri, Sep 17, 2021 at 1:20 PM
Subject: New Version Notification for draft-dickson-dnsop-glueless-01.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dnsop-glueless-01.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-glueless
Revision:   01
Title:  Operating a Glueless DNS Authority Server
Document date:  2021-09-17
Group:  Individual Submission
Pages:  7
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-01.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-glueless/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-glueless
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-glueless-01

Abstract:
   This Internet Draft proposes a method for protecting authority
   servers against MITM and poisoning attacks, using a domain naming
   strategy to not require glue A/ records and use of DNSSEC.

   This technique assumes the use of validating resolvers.

   MITM and poisoning attacks should only be effective/possible against
   unsigned domains.

   However, until all domains are signed, this guidance is relevant, in
   that it can limit the attack surface of unsigned domains.

   This guidance should be combined with [I-D.dickson-dnsop-ds-hack]




The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-ds-hack-01.txt

[Brian Dickson]

Hi, DNSOP folks,
I have been working on the "unsigned NS record" problem (and related
"unsigned glue record" problem).

I think this is relatively widely applicable, even though it was originally
motivated by a problem that needed to be solved within DPRIVE.
(That problem is the subject of a draft I will be posting in DPRIVE, for
those interested.)

I think it's fairly straightforward, but it is difficult to tell without
getting feedback, so please let me know what you think.

Brian Dickson

-- Forwarded message -
From: 
Date: Fri, Sep 17, 2021 at 1:29 AM
Subject: New Version Notification for draft-dickson-dnsop-ds-hack-01.txt
To: Brian Dickson 



A new version of I-D, draft-dickson-dnsop-ds-hack-01.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:   draft-dickson-dnsop-ds-hack
Revision:   01
Title:  DS Algorithms for Securing NS and Glue
Document date:  2021-09-17
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-01.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dnsop-ds-hack/
Html:
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-01.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-ds-hack-01

Abstract:
   This Internet Draft proposes a mechanism to encode relevant data for
   NS records on the parental side of a zone cut by encoding them in DS
   records based on a new DNSKEY algorithm.

   Since DS records are signed by the parent, this creates a method for
   validation of the otherwise unsigned delegation records.

   Notably, support for updating DS records in a parent zone is already
   present (by necessity) in the Registry-Registrar-Registrant (RRR)
   provisioning system, EPP.  Thus, no changes to the EPP protocol are
   needed, and no changes to registry database or publication systems
   upstream of the DNS zones published by top level domains (TLDs).

   This NS validation mechanism is beneficial if the name server _names_
   need to be validated prior to use.




The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-svcb-https-06.txt

[Dick Franks]

Feedback on SVCB draft 06 as requested.

On Mon, 28 Jun 2021 at 02:39, Tim Wicinski  wrote:
>8
>
> The chairs would like the WG to review these changes, and give us some 
> feedback.


6.1.  "alpn" and "no-default-alpn"

   The presentation "value" SHALL be a comma-separated list
   (Appendix A.1) of one or more "alpn-id"s.  Zone file implementations
   MAY disallow the "," and "\" characters instead of implementing the
   "value-list" escaping procedure, relying on the opaque key format
   (e.g. "key1=\002h2") in the event that these characters are needed.

If implementations MAY ignore the escape mechanism Appendix A.1 completely,
there is little incentive to do otherwise.

However, implementations that do not exercise that option expose themselves
to a litany of potential security weaknesses:

These range from argument strings which produce corrupt content:

   example.com.   SVCB   1 example.com. ipv6hint="2001:db8:5c:5c5c::1"

not ok 29 - SVCB ipv6hint shrinkage
#   Failed test 'SVCB ipv6hint shrinkage'
#   at test.pl line 149.
#  got: 'example.com.INSVCB( \# 33 0001
076578616d706c6503636f6d00 ; example.com.
# 0006 000e 20010db8005c0001 )'
# expected: 'example.com.INSVCB( \# 35 0001
076578616d706c6503636f6d00 ; example.com.
# 0006 0010 20010db8005c5c5c0001 )'

to crafted RRs which silently subvert the parsing process in undesirable ways:

   example.com.   SVCB   1 example.com.
ipv4hint="92.48.55.48,92.48.56.53,92.48.54.54,92.48.56.50"

not ok 30 - SVCB ipv4hint subversion
#   Failed test 'SVCB ipv4hint subversion'
#   at test.pl line 149.
#  got: 'example.com.INSVCB( \# 23 0001
076578616d706c6503636f6d00 ; example.com.
# 0004 0004 46554252 )'
# expected: 'example.com.INSVCB( \# 35 0001
076578616d706c6503636f6d00 ; example.com.
# 0004 0010 5c3037305c3038355c3036365c303832 )'


D.3.  Failure cases

The following additional test vectors are listed below the
corresponding requirement.

 [9, para 1]
 In presentation format, the value is a [SINGLE] ECHConfigList encoded
in Base64.

  example.com.  SVCB  1 foo.example.com. ech; missing argument
  example.com.  SVCB  1 foo.example.com. ech=b25l,dHdv  ; multiple arguments

 [6.2, para 2]
 The presentation "value" of the SvcParamValue is a [SINGLE] decimal
integer between 0 and 65535 in ASCII.

 Note: Character set cannot be specified here; it is whatever the
platform or zone file uses (EBCDIC for example).

  example.com.  SVCB  1 foo.example.com. port=1234,4678 ; multiple arguments

 [6.1, para 6]
 When "no-default-alpn" is specified in an RR, "alpn" must also be
specified in order for the RR to be "self-consistent" (Section 2.4.3).

  example.com.  SVCB  1 foo.example.com. (
  no-default-alpn   ; without expected alpn
  )

D.2.  Service form

The test vector for unsorted SvcParams would be better expressed using
numerical keys and disentangled from extraneous clutter.

  example.com.  SVCB  1 foo.example.org. (  ; unsorted SvcParam keys
  key23609 key23600 mandatory=key23609,key23600
  )

--rwf



>
> -- Forwarded message -
> From: 
> Date: Wed, Jun 16, 2021 at 10:29 AM
> Subject: New Version Notification - draft-ietf-dnsop-svcb-https-06.txt
> To: Tim Wicinski 
>
>
>
> A new version (-06) has been submitted for draft-ietf-dnsop-svcb-https:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.txt
> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.html
>
>
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>
> Diff from previous version:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-06
>
> IETF Secretariat.
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

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

[DNSOP] Fwd: New Version Notification for draft-thomassen-dnsop-dnssec-bootstrapping-00.txt

[Peter Thomassen]

Hi all,

As far as I'm concerned, the pain in maintaining a secure delegation is often 
too high, and way too many DNS delegations are still insecure. I presume that 
many of you agree, which (supposedly) is why mechanisms like RFC 8078 have been 
created. And indeed, RFC 8078 is great for rollovers.

Unfortunately, current methods for bootstrapping a secure delegation are 
manual/slow/out-of-band/error-prone (registrar's web interface) or 
slow/unauthenciated (monitor CDS/CDNSKEY for a few days via TCP and hope for 
the best). As an operator that's trying to push DNSSEC, I wish this situation 
could be improved.

With the below draft, I am proposing how I think the problem could be solved 
in-band, authenticated and immediate. I've asked some registries, and they see 
value in it. While I know that the WG currently does not adopt any documents, I 
still would like to share it, and possibly have a discussion about it. Is there 
any interest in this?

Thanks,
Peter


 Forwarded Message 
Subject: New Version Notification for 
draft-thomassen-dnsop-dnssec-bootstrapping-00.txt
Date: Tue, 29 Jun 2021 17:46:53 -0700
From: internet-dra...@ietf.org
To: Peter Thomassen 


A new version of I-D, draft-thomassen-dnsop-dnssec-bootstrapping-00.txt
has been successfully submitted by Peter Thomassen and posted to the
IETF repository.

Name:   draft-thomassen-dnsop-dnssec-bootstrapping
Revision:   00
Title:  DNSSEC Bootstrapping
Document date:  2021-06-30
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-thomassen-dnsop-dnssec-bootstrapping/
Html:   
https://www.ietf.org/archive/id/draft-thomassen-dnsop-dnssec-bootstrapping-00.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-thomassen-dnsop-dnssec-bootstrapping


Abstract:
   This document describes an authenticated in-band method for automatic
   signaling of a DNS zone's delegation signer information from the
   zone's DNS operator.  The zone's registrar or registry may
   subsequently use this signal for automatic DS record provisioning in
   the parent zone.

  



The IETF Secretariat





OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification - draft-ietf-dnsop-svcb-https-06.txt

[Tim Wicinski]

All

The SVCB Authors took some of your last minute requests and they did an
update which
gives more guidance and explanations around Alt-Svc, but also more
explanations around
the requirements.

The chairs would like the WG to review these changes, and give us some
feedback.  Take
a look at the diff right here:

https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-06

We're going to look for any comments over the coming week, so please send
any comments
in by Friday July 2nd.

thanks
tim

-- Forwarded message -
From: 
Date: Wed, Jun 16, 2021 at 10:29 AM
Subject: New Version Notification - draft-ietf-dnsop-svcb-https-06.txt
To: Tim Wicinski 



A new version (-06) has been submitted for draft-ietf-dnsop-svcb-https:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.txt
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.html


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-06

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Brian Dickson]

On Tue, Jun 15, 2021 at 12:03 PM Paul Wouters  wrote:

> On Tue, 15 Jun 2021, Shumon Huque wrote:
>
> > On Tue, Jun 15, 2021 at 12:46 PM Tim Wicinski 
> wrote:
> >
> > Yes, Stephane, we were envisioning recommending an
> underscore label. Of course, that leads to how to avoid collisions in that
> > space, and whether we need to establish a registry of
> application service names.
> >
> >
> > You mean, a different registry than this one
> >
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
> >
> > tim
> >
> >
> > Tim - yes, I think this would be a bit different. The above is for IETF
> defined protocols. This one (if we think it's a good idea) would have to
> encompass
> > arbitrary Internet application services, many that could be proprietary
> services of companies.
>
>  I am one of the underscored-globally-scoped-dns-node-names Experts
>
> The _underscore registry is "Expert Review" only, meaning it is not only
> used for IETF defined protocols. It's only goal is to be a place where
> people can register a unique name to avoid name collision between
> different protocols/applications using it.
>
> As such, it would be fine for this draft to commend registration there.
> It could also start its own _underscore registry.
>
> 
>
> Of course, if people ensure the names they use are somehow linked to
> their product of business name, it becomes fairly unique to begin
> with, and a registry might not be needed. Like people shouldn't be
> using _registration or _website_auth or something generic like that.
> My personal preference would be to focus stronger on generating proper
> names (and embedded expire / recurring check within the name) that
> would ensure no central registry of any kind would be needed.
>

The only real issue I see is managing the underscore namespace as a flat
namespace.
Given that DNS itself was engineered in part to be hierarchical as a
solution to the scaling problems of hosts.txt,
maybe using an underscore scheme that is hierarchical would solve some/many
of these problems?
(Perhaps carved out with its own underscore suffix.)

The analogy that comes to mind is the MIB tree, with the public branch
(.1.3.6.1.2.1) and the enterprise (.1.3.6.1.4.1).
The enterprise portion of the tree has a very large number of nodes.
Using numeric values rather than names avoids name collisions.

These are just suggestions though.

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Shumon Huque]

On Tue, Jun 15, 2021 at 3:06 PM Paul Wouters  wrote:

>
> Please try and recommend stronger naming guidelines so that a registry
> is not _needed_
>

Ok, I'm fine with punting on the registry idea for now ..

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Paul Wouters]

On Tue, 15 Jun 2021, Shumon Huque wrote:


  No, it's for anyone with a plausible application. It already includes
  _validation-contactemail and _validation-contactphone from the CAB.


I would rephrase this as "for anyone who foolishly made a really bad
generic name in the past and is now stuck with it and wants to avoid
anyone else picking the same foolish name".


In that case, we could use this one.


Please try and recommend stronger naming guidelines so that a registry
is not _needed_

Paul

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Paul Wouters]

On Tue, 15 Jun 2021, Shumon Huque wrote:


On Tue, Jun 15, 2021 at 12:46 PM Tim Wicinski  wrote:

Yes, Stephane, we were envisioning recommending an underscore 
label. Of course, that leads to how to avoid collisions in that
space, and whether we need to establish a registry of application 
service names.


You mean, a different registry than this one
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

tim


Tim - yes, I think this would be a bit different. The above is for IETF defined 
protocols. This one (if we think it's a good idea) would have to encompass
arbitrary Internet application services, many that could be proprietary 
services of companies.


 I am one of the underscored-globally-scoped-dns-node-names Experts

The _underscore registry is "Expert Review" only, meaning it is not only
used for IETF defined protocols. It's only goal is to be a place where
people can register a unique name to avoid name collision between
different protocols/applications using it.

As such, it would be fine for this draft to commend registration there.
It could also start its own _underscore registry.



Of course, if people ensure the names they use are somehow linked to
their product of business name, it becomes fairly unique to begin
with, and a registry might not be needed. Like people shouldn't be
using _registration or _website_auth or something generic like that.
My personal preference would be to focus stronger on generating proper
names (and embedded expire / recurring check within the name) that
would ensure no central registry of any kind would be needed.

Paul

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Shumon Huque]

On Tue, Jun 15, 2021 at 1:51 PM John Levine  wrote:

> It appears that Shumon Huque   said:
> >> You mean, a different registry than this one
> >>
> >>
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
> >
> >Tim - yes, I think this would be a bit different. The above is for IETF
> >defined protocols.
>
> No, it's for anyone with a plausible application. It already includes
> _validation-contactemail and _validation-contactphone from the CAB.
>

Ah, thanks for correcting me ..

In that case, we could use this one.

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[John Levine]

It appears that Shumon Huque   said:
>> You mean, a different registry than this one
>>
>> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
>
>Tim - yes, I think this would be a bit different. The above is for IETF
>defined protocols. 

No, it's for anyone with a plausible application. It already includes
_validation-contactemail and _validation-contactphone from the CAB.

R's,
John

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Tim Wicinski]

On Tue, Jun 15, 2021 at 12:50 PM Shumon Huque  wrote:

> On Tue, Jun 15, 2021 at 12:46 PM Tim Wicinski  wrote:
>
>>
>> Yes, Stephane, we were envisioning recommending an underscore label. Of
>>> course, that leads to how to avoid collisions in that space, and whether we
>>> need to establish a registry of application service names.
>>>
>>
>> You mean, a different registry than this one
>>
>> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
>>
>> tim
>>
>
> Tim - yes, I think this would be a bit different. The above is for IETF
> defined protocols. This one (if we think it's a good idea) would have to
> encompass arbitrary Internet application services, many that could be
> proprietary services of companies.
>
> Shumon.
>
>
Ok, I can see that.


The survey you're doing will help with that.

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Shumon Huque]

On Tue, Jun 15, 2021 at 12:46 PM Tim Wicinski  wrote:

>
> Yes, Stephane, we were envisioning recommending an underscore label. Of
>> course, that leads to how to avoid collisions in that space, and whether we
>> need to establish a registry of application service names.
>>
>
> You mean, a different registry than this one
>
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
>
> tim
>

Tim - yes, I think this would be a bit different. The above is for IETF
defined protocols. This one (if we think it's a good idea) would have to
encompass arbitrary Internet application services, many that could be
proprietary services of companies.

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Tim Wicinski]

On Tue, Jun 15, 2021 at 12:38 PM Shumon Huque  wrote:

> On Tue, Jun 15, 2021 at 12:28 PM Shivan Kaul Sahib <
> shivankaulsa...@gmail.com> wrote:
>
>> Hi Stephane!
>>
>>>
>>> Section 4.1: you do not mention a recommended name for the
>>> subdomain. Should we suggest a name starting with an underscore, to
>>> limit the risk of collisions and to emphasize it is not a host name?
>>> (On the other hand, some users may have a limited DNS provisioning
>>> interface, which enforces a LDH restriction.)
>>>
>>
>> This draft is intended to be a survey of existing techniques and broad
>> recommendations that can be derived from the survey (hence we only discuss
>> the value of targeted domain verification). Our thought was that we should
>> leave concrete best practices for a later draft.
>>
>
> Shivan: a survey is the initial goal. But my thinking was: assuming there
> is interest in the draft first (which there appears to be), we could work
> on recommendations in a later iteration of this draft (and not a new one,
> although I could be persuaded).
>
> Yes, Stephane, we were envisioning recommending an underscore label. Of
> course, that leads to how to avoid collisions in that space, and whether we
> need to establish a registry of application service names.
>

You mean, a different registry than this one
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Shumon Huque]

On Tue, Jun 15, 2021 at 12:28 PM Shivan Kaul Sahib <
shivankaulsa...@gmail.com> wrote:

> Hi Stephane!
>
>>
>> Section 4.1: you do not mention a recommended name for the
>> subdomain. Should we suggest a name starting with an underscore, to
>> limit the risk of collisions and to emphasize it is not a host name?
>> (On the other hand, some users may have a limited DNS provisioning
>> interface, which enforces a LDH restriction.)
>>
>
> This draft is intended to be a survey of existing techniques and broad
> recommendations that can be derived from the survey (hence we only discuss
> the value of targeted domain verification). Our thought was that we should
> leave concrete best practices for a later draft.
>

Shivan: a survey is the initial goal. But my thinking was: assuming there
is interest in the draft first (which there appears to be), we could work
on recommendations in a later iteration of this draft (and not a new one,
although I could be persuaded).

Yes, Stephane, we were envisioning recommending an underscore label. Of
course, that leads to how to avoid collisions in that space, and whether we
need to establish a registry of application service names.

Section 5: should we also add that, specially if the zone is not
>> signed, multi-vantage-point checking is recommended (Let's Encrypt
>> already does it)?
>>
>
> Interesting, I raised an issue here:
> https://github.com/ShivanKaul/draft-sahib-domain-verification-techniques/issues/18
>

Yeah, that's a good idea.

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Shivan Kaul Sahib]

Thanks Tony!

Best practice for providers ought to be to document re-validation
> requirements very prominently and clearly. (In my experience the common
> ones are not too bad but occasionally we have to guess, so maybe a service
> stops working for mysterious reasons 30 or 90 days later.)
>

Agreed! We currently have some text in section 4.3

around time-bound checking but we should add this. I raised an issue

.

>
> It's kind of ugly the way static verification records clutter
> up the place, but on the other hand it is a useful protection against
> subdomain takeover attacks. So I hope that this document will have a good
> survey of the security considerations.
>
> Here's an overview of subdomain takeovers
>
> https://www.csoonline.com/article/3601007/how-to-avoid-subdomain-takeover-in-azure-environments.html


My understanding of subdomain takeovers is that it happens because of
dangling records. Would you mind expanding on this?

>
>
> Tony.
> --
> f.anthony.n.finchhttps://dotat.at/
> Southeast Fitzroy: Northerly or northeasterly 5 to 7, occasionally
> gale 8 at first. Moderate or rough. Fair. Good.
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Shivan Kaul Sahib]

Hi Stephane!

>
> Section 4.1: you do not mention a recommended name for the
> subdomain. Should we suggest a name starting with an underscore, to
> limit the risk of collisions and to emphasize it is not a host name?
> (On the other hand, some users may have a limited DNS provisioning
> interface, which enforces a LDH restriction.)
>

This draft is intended to be a survey of existing techniques and broad
recommendations that can be derived from the survey (hence we only discuss
the value of targeted domain verification). Our thought was that we should
leave concrete best practices for a later draft.

>
> Section 5: should we also add that, specially if the zone is not
> signed, multi-vantage-point checking is recommended (Let's Encrypt
> already does it)?
>

Interesting, I raised an issue here:
https://github.com/ShivanKaul/draft-sahib-domain-verification-techniques/issues/18
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Stephane Bortzmeyer]

On Thu, Jun 10, 2021 at 04:26:44PM -0700,
 Shivan Kaul Sahib  wrote 
 a message of 164 lines which said:

> Hi all, Shumon and I have been working on an early draft that
> surveys current DNS domain verification techniques. Depending on how
> it goes, we hope to eventually explore if we can come up with some
> best practices.

Section 4.1: you do not mention a recommended name for the
subdomain. Should we suggest a name starting with an underscore, to
limit the risk of collisions and to emphasize it is not a host name?
(On the other hand, some users may have a limited DNS provisioning
interface, which enforces a LDH restriction.)

Section 5: should we also add that, specially if the zone is not
signed, multi-vantage-point checking is recommended (Let's Encrypt
already does it)?


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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Tony Finch]

Shivan Kaul Sahib  wrote:

> Hi all, Shumon and I have been working on an early draft that surveys
> current DNS domain verification techniques. Depending on how it goes, we
> hope to eventually explore if we can come up with some best practices.

This looks like a useful document!

One thing that's operationally awkward for me is how some providers do
one-time verifications, and others re-validate periodically. I suppose
there is another distinction between static re-validation done by (e.g.)
Google, and dynamic renewal as required by ACME.

Best practice for providers ought to be to document re-validation
requirements very prominently and clearly. (In my experience the common
ones are not too bad but occasionally we have to guess, so maybe a service
stops working for mysterious reasons 30 or 90 days later.)

It's kind of ugly the way static verification records clutter
up the place, but on the other hand it is a useful protection against
subdomain takeover attacks. So I hope that this document will have a good
survey of the security considerations.

Here's an overview of subdomain takeovers
https://www.csoonline.com/article/3601007/how-to-avoid-subdomain-takeover-in-azure-environments.html

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Southeast Fitzroy: Northerly or northeasterly 5 to 7, occasionally
gale 8 at first. Moderate or rough. Fair. Good.

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

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Tim Wicinski]

Paul

We've been talking with Shivan and Shumon about the document, and I feel I
already asked them to be prepared to present at the next meeting on this.

I also suggested that they should also with the Application Area, for
feedback.

tim


On Thu, Jun 10, 2021 at 10:22 PM Paul Wouters  wrote:

> Thanks for doing this work!
>
> I’ve read this a while ago when you gave me a preview and this is
> important work that you should present at the next IETF and hopefully we
> can adopt and put though
> reasonably fast - the market needs our guidance.
>
> (For those who think there is no problem, dig txt cnn.com)
>
> Paul
>
> Sent using a virtual keyboard on a phone
>
> On Jun 10, 2021, at 19:27, Shivan Kaul Sahib 
> wrote:
>
> 
> Hi all, Shumon and I have been working on an early draft that surveys
> current DNS domain verification techniques. Depending on how it goes, we
> hope to eventually explore if we can come up with some best practices.
>
> We plan to ask for time to present it at the IETF 111 DNSOP meeting. In
> the meantime, please let us know if this is of interest!
>
> -- Forwarded message -
> From: 
> Date: Thu, Jun 10, 2021 at 9:27 AM
> Subject: New Version Notification for
> draft-sahib-domain-verification-techniques-02.txt
> To: Shivan Sahib , Shumon Huque <
> shu...@gmail.com>
>
>
>
> A new version of I-D, draft-sahib-domain-verification-techniques-02.txt
> has been successfully submitted by Shivan Sahib and posted to the
> IETF repository.
>
> Name:   draft-sahib-domain-verification-techniques
> Revision:   02
> Title:  Survey of Domain Verification Techniques using DNS
> Document date:  2021-06-10
> Group:  Individual Submission
> Pages:  9
> URL:
> https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/
> Html:
> https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.html
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-sahib-domain-verification-techniques
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-sahib-domain-verification-techniques-02
>
> Abstract:
>Many services on the Internet need to verify ownership or control of
>domains in the Domain Name System (DNS) [RFC1034] [RFC1035].  This
>verification often relies on adding or editing DNS records within the
>domain.  This document surveys various techniques in wide use today,
>the pros and cons of each, and possible improvements.
>
> Discussion Venues
>
>This note is to be removed before publishing as an RFC.
>
>Source for this draft and an issue tracker can be found at
>https://github.com/ShivanKaul/draft-sahib-domain-verification-
>techniques.
>
>
>
>
> The IETF Secretariat
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Paul Wouters]

Thanks for doing this work!

I’ve read this a while ago when you gave me a preview and this is important 
work that you should present at the next IETF and hopefully we can adopt and 
put though
reasonably fast - the market needs our guidance.

(For those who think there is no problem, dig txt cnn.com)

Paul

Sent using a virtual keyboard on a phone

> On Jun 10, 2021, at 19:27, Shivan Kaul Sahib  
> wrote:
> 
> 
> Hi all, Shumon and I have been working on an early draft that surveys current 
> DNS domain verification techniques. Depending on how it goes, we hope to 
> eventually explore if we can come up with some best practices.
> 
> We plan to ask for time to present it at the IETF 111 DNSOP meeting. In the 
> meantime, please let us know if this is of interest! 
> 
> -- Forwarded message -
> From: 
> Date: Thu, Jun 10, 2021 at 9:27 AM
> Subject: New Version Notification for 
> draft-sahib-domain-verification-techniques-02.txt
> To: Shivan Sahib , Shumon Huque 
> 
> 
> 
> A new version of I-D, draft-sahib-domain-verification-techniques-02.txt
> has been successfully submitted by Shivan Sahib and posted to the
> IETF repository.
> 
> Name:   draft-sahib-domain-verification-techniques
> Revision:   02
> Title:  Survey of Domain Verification Techniques using DNS
> Document date:  2021-06-10
> Group:  Individual Submission
> Pages:  9
> URL:
> https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/
> Html:   
> https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.html
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-sahib-domain-verification-techniques
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-sahib-domain-verification-techniques-02
> 
> Abstract:
>Many services on the Internet need to verify ownership or control of
>domains in the Domain Name System (DNS) [RFC1034] [RFC1035].  This
>verification often relies on adding or editing DNS records within the
>domain.  This document surveys various techniques in wide use today,
>the pros and cons of each, and possible improvements.
> 
> Discussion Venues
> 
>This note is to be removed before publishing as an RFC.
> 
>Source for this draft and an issue tracker can be found at
>https://github.com/ShivanKaul/draft-sahib-domain-verification-
>techniques.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-sahib-domain-verification-techniques-02.txt

[Shivan Kaul Sahib]

Hi all, Shumon and I have been working on an early draft that surveys
current DNS domain verification techniques. Depending on how it goes, we
hope to eventually explore if we can come up with some best practices.

We plan to ask for time to present it at the IETF 111 DNSOP meeting. In
the meantime, please let us know if this is of interest!

-- Forwarded message -
From: 
Date: Thu, Jun 10, 2021 at 9:27 AM
Subject: New Version Notification for
draft-sahib-domain-verification-techniques-02.txt
To: Shivan Sahib , Shumon Huque 



A new version of I-D, draft-sahib-domain-verification-techniques-02.txt
has been successfully submitted by Shivan Sahib and posted to the
IETF repository.

Name:   draft-sahib-domain-verification-techniques
Revision:   02
Title:  Survey of Domain Verification Techniques using DNS
Document date:  2021-06-10
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.txt
Status:
https://datatracker.ietf.org/doc/draft-sahib-domain-verification-techniques/
Html:
https://www.ietf.org/archive/id/draft-sahib-domain-verification-techniques-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-sahib-domain-verification-techniques
Diff:
https://www.ietf.org/rfcdiff?url2=draft-sahib-domain-verification-techniques-02

Abstract:
   Many services on the Internet need to verify ownership or control of
   domains in the Domain Name System (DNS) [RFC1034] [RFC1035].  This
   verification often relies on adding or editing DNS records within the
   domain.  This document surveys various techniques in wide use today,
   the pros and cons of each, and possible improvements.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/ShivanKaul/draft-sahib-domain-verification-
   techniques.




The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-07.txt

[tirumal reddy]

Hi all,

This revision https://tools.ietf.org/html/draft-reddy-dnsop-error-page-07
addresses comments from the WG during the presentation at IETF-110.

As a reminder, it defines an Error page URI EDNS0 option to return an URI
Template which when accessed provides the reason the DNS query was
filtered. It discusses mandatory rules (e.g., DoH and strict privacy
profile in DoT) to process the Error page URI EDNS0 option.

Further comments and suggestions are welcome.

Cheers,
-Tiru

-- Forwarded message -
From: 
Date: Wed, 21 Apr 2021 at 11:10
Subject: New Version Notification for draft-reddy-dnsop-error-page-07.txt
To: Tirumaleswar Reddy.K , Dan Wing <
dwing-i...@fuggles.com>, Mohamed Boucadair ,
Neil Cook 



A new version of I-D, draft-reddy-dnsop-error-page-07.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-dnsop-error-page
Revision:   07
Title:  DNS Access Denied Error Page
Document date:  2021-04-20
Group:  Individual Submission
Pages:  14
URL:
https://www.ietf.org/archive/id/draft-reddy-dnsop-error-page-07.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page
Htmlized:   https://tools.ietf.org/html/draft-reddy-dnsop-error-page-07
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-dnsop-error-page-07

Abstract:
   When a DNS server filters a query, the response to such query conveys
   no detailed explanation that elaborates why that query was blocked,
   leading thus to end-user confusion.  A solution to this problem is
   needed in order to enhance the user experience.

   This document defines a method to return an URI that explains the
   reason why a DNS query was filtered by a DNS server.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refer-00.txt

[Bob Harold]

On Fri, Feb 12, 2021 at 11:08 AM Joe Abley  wrote:

> Hi all,
>
> I have discovered that without liberal access to bars and hallways at
> in-person IETF meetings, I no longer know how to tell the difference
> between ambition and insanity when it comes to technical proposals. I am
> quite prepared to find out that in this case the needle is at the crazy end
> of the scale.
>
> Happy Friday!
>
>
> Joe
>
> Begin forwarded message:
>
> *From: *internet-dra...@ietf.org
> *Subject: **New Version Notification for draft-jabley-dnsop-refer-00.txt*
> *Date: *12 February 2021 at 10:52:38 EST
> *To: *"Joe Abley" 
>
>
> A new version of I-D, draft-jabley-dnsop-refer-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
>
> Name: draft-jabley-dnsop-refer
> Revision: 00
> Title: REFER: A New Referral Mechanism for the DNS
> Document date: 2021-02-12
> Group: Individual Submission
> Pages: 14
> URL:
> https://www.ietf.org/archive/id/draft-jabley-dnsop-refer-00.txt
> Status: https://datatracker.ietf.org/doc/draft-jabley-dnsop-refer/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer
> Htmlized:   https://tools.ietf.org/html/draft-jabley-dnsop-refer-00
>
>
> Abstract:
>   The Domain Name System (DNS) incorporates a namespace that is
>   comprised, in practice, of multiple so-called zones.  Each zone is,
>   in principal, a finite tree structure which can be administered
>   autonomously, and is connected to exactly one parent zone and zero or
>   more child zones.  These connection points are known as zone cuts; a
>   parent zone contains information that allows the servers responsible
>   for the child zone to be found.
>
>   The current DNS specification encodes that information about child
>   zones using an "NS" resource record set in the parent zone, and a
>   corresponding "NS" resource record set in the child zone.  These two
>   resource record sets have identical owner names, class, and resource
>   record type but can differ in other respects such as the time-to-live
>   (TTL) attribute, the resource record data associated with each set
>   and the availability of cryptographic signatures.  This property of
>   being similar, related but potentially different has led to
>   operational complexity.
>
>   This document proposes a change to how zone cuts are encoded in the
>   parent zone, allowing the resource records in the parent and the
>   child zone to be more clearly distinguished and protected separately
>   using cryptographic signatures.
>
>   It is not at all clear that this is a good idea.  To restate in
>   stronger terms, the goal of the experiment described in this document
>   is to determine just how bad an idea this is.
>
>
> I like this.  But don't we also need to sign the glue A and  records
if they are in the child zone?
(I wonder if something like the SVCB record, to include the NS info, plus A
and , might be better.)

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refer-00.txt

[Paul Wouters]

On Fri, 12 Feb 2021, Joe Abley wrote:


I have discovered that without liberal access to bars and hallways at in-person 
IETF meetings, I no longer know how to tell the difference
between ambition and insanity when it comes to technical proposals. I am quite 
prepared to find out that in this case the needle is at the crazy
end of the scale.


So I think execsum is, REFER is like NS for client, but signed like DS.

What does that buy us. A MITM can't forge the NS to trick a validator
to a dead end (presuming a DS protects them from actual bogus data)

That is the same gain from getting TLS to AUTH servers. But REFER works
without needing transport security.

For everyone else downstream of the validating resolver, they ofcourse
can already be given DS plus child-side (signed) NS records.

And this solution would still be missing a pubkey that can be used
to encrypt the connection to the delegated child zone nameservers.

Seeing how things would likely misimplement REFER, or run into issues
because it gets semi supported through generic records and just flies
along the wrong side of the zone cut, I'd say the dangers of this do
not outweigh the gains.

If we do something drastic like this, at least provide not only the
validatable child NS records, also provide whatever is needed to setup a
fully encrypted connetion to the child's nameserver's so we can get
a fully private query chain with no leaks.

Paul

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

Re: [DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refer-00.txt

[Brian Dickson]

I like this proposal, look forward to experimenting with this.

I'm not sure about how to defend against downgrade attacks, without
potentially having to touch some other DNSSEC-specific standards. I admit
to not having looked at them again, recently, with this in mind, so the
question I'm asking is something that might have an obvious answer.
In a signed zone (parent) with a zone cut, which includes a REFER record,
with or without the delegation being signed (i.e. with or without a DS
record), what would/could protect against a downgrade?

I think this may need to be analogous to the handling of signed
delegations, if the client (resolver) is DNSSEC-aware, in doing validation.

I think NSEC(3) record(s) proving something would be necessary and
sufficient, to prove the (non-)existence of NS and/or REFER records, and to
include the REFER and RRSIG(REFER) even if RO is not present (possibly
stripped). Synthesis of NS from REFER would probably be analogous to
synthesis of CNAME from DNAME.

I like this a lot, actually. The only question is really uptake by
registries/TLDs and the root.

Brian

On Fri, Feb 12, 2021 at 10:38 AM Ben Schwartz  wrote:

> This is a fun proposal, Joe.  (I think it should probably also go to
> DPRIVE, although it's mostly the same folks.)
>
> Regarding the Security Considerations, I would suggest that REFER-aware
> recursive resolvers (1) should also implement QNAME minimization, and (2)
> should send a REFER query in parallel with any shortened-QNAME query.  It
> seems to me that should be roughly sufficient to prevent the downgrade
> attack (if the parent is signed) without adding latency.
>
> On Fri, Feb 12, 2021 at 11:08 AM Joe Abley  wrote:
>
>> Hi all,
>>
>> I have discovered that without liberal access to bars and hallways at
>> in-person IETF meetings, I no longer know how to tell the difference
>> between ambition and insanity when it comes to technical proposals. I am
>> quite prepared to find out that in this case the needle is at the crazy end
>> of the scale.
>>
>> Happy Friday!
>>
>>
>> Joe
>>
>>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-jabley-dnsop-refer-00.txt

[Joe Abley]

Hi all,

I have discovered that without liberal access to bars and hallways at in-person 
IETF meetings, I no longer know how to tell the difference between ambition and 
insanity when it comes to technical proposals. I am quite prepared to find out 
that in this case the needle is at the crazy end of the scale.

Happy Friday!


Joe

> Begin forwarded message:
> 
> From: internet-dra...@ietf.org
> Subject: New Version Notification for draft-jabley-dnsop-refer-00.txt
> Date: 12 February 2021 at 10:52:38 EST
> To: "Joe Abley" 
> 
> 
> A new version of I-D, draft-jabley-dnsop-refer-00.txt
> has been successfully submitted by Joe Abley and posted to the
> IETF repository.
> 
> Name: draft-jabley-dnsop-refer
> Revision: 00
> Title:REFER: A New Referral Mechanism for the DNS
> Document date:2021-02-12
> Group:Individual Submission
> Pages:14
> URL:
> https://www.ietf.org/archive/id/draft-jabley-dnsop-refer-00.txt
> Status: https://datatracker.ietf.org/doc/draft-jabley-dnsop-refer/
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-jabley-dnsop-refer
> Htmlized:   https://tools.ietf.org/html/draft-jabley-dnsop-refer-00
> 
> 
> Abstract:
>   The Domain Name System (DNS) incorporates a namespace that is
>   comprised, in practice, of multiple so-called zones.  Each zone is,
>   in principal, a finite tree structure which can be administered
>   autonomously, and is connected to exactly one parent zone and zero or
>   more child zones.  These connection points are known as zone cuts; a
>   parent zone contains information that allows the servers responsible
>   for the child zone to be found.
> 
>   The current DNS specification encodes that information about child
>   zones using an "NS" resource record set in the parent zone, and a
>   corresponding "NS" resource record set in the child zone.  These two
>   resource record sets have identical owner names, class, and resource
>   record type but can differ in other respects such as the time-to-live
>   (TTL) attribute, the resource record data associated with each set
>   and the availability of cryptographic signatures.  This property of
>   being similar, related but potentially different has led to
>   operational complexity.
> 
>   This document proposes a change to how zone cuts are encoded in the
>   parent zone, allowing the resource records in the parent and the
>   child zone to be more clearly distinguished and protected separately
>   using cryptographic signatures.
> 
>   It is not at all clear that this is a good idea.  To restate in
>   stronger terms, the goal of the experiment described in this document
>   is to determine just how bad an idea this is.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 

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

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-05.txt

[tirumal reddy]

Hi Joey,

Thanks for the interest in the draft. We published a revised draft
https://tools.ietf.org/html/draft-reddy-dnsop-error-page-06  to address the
comments from the WG during the presentation at IETF-109.

Further comments and suggestions are welcome.

Cheers,
-Tiru

On Sat, 19 Dec 2020 at 02:57, Joey S  wrote:

> Dear Tirumal, dnsop,
>
> Following up on the last IETF session and observations regarding the
> usability of this draft at the end of the meeting, this draft covers 2
> important areas from my perspective: DNS error information made available
> to the end-users as opposed to (mainly) administrators/operators from the
> extended-DNS-errors RFC (rfc8914); the promotion of increased DNS security
> as a means to achieve reliable information.
>
> For those two reasons I'd like to ask:
>
>- Are there specific sections of the I-D that require input?
>- Are there remaining questions from the 109 meeting?
>- What's currently needed for potentially moving forward with WG
>adoption?
>
> Thank you,
>
> --
> Joey Salazar
> Digital Sr. Programme Officer
> ARTICLE 19
> 6E9C 95E5 5BED 9413 5D08 55D5 0A40 4136 0DF0 1A91
>
> On 14-Oct-20 10:50 PM, tirumal reddy wrote:
>
> Hi all,
>
> This revision https://tools.ietf.org/html/draft-reddy-dnsop-error-page-05
> updates security considerations section to address comments from the WG
> during the presentation at IETF-108.
>
> As a reminder, it discusses a method to return an URL that explains the
> reason the DNS query was filtered. It defines an Error page URI EDNS0
> option to return an URI Template which when accessed provides the reason
> the DNS query was filtered. The Error Page URI Template is protected with a
> signature for data origin authentication. It discusses mandatory rules
> (e.g., DoH and strict privacy profile in DoT) to process the Error page URI
> EDNS0 option.
>
> Further comments and suggestions are welcome.
>
> Cheers,
> -Tiru
>
> -- Forwarded message -
> From: 
> Date: Wed, 14 Oct 2020 at 11:25
> Subject: New Version Notification for draft-reddy-dnsop-error-page-05.txt
> To: Tirumaleswar Reddy.K , Mohamed Boucadair <
> mohamed.boucad...@orange.com>, Neil Cook , Dan
> Wing 
>
>
>
> A new version of I-D, draft-reddy-dnsop-error-page-05.txt
> has been successfully submitted by Tirumaleswar Reddy and posted to the
> IETF repository.
>
> Name:   draft-reddy-dnsop-error-page
> Revision:   05
> Title:  DNS Access Denied Error page
> Document date:  2020-10-13
> Group:  Individual Submission
> Pages:  16
> URL:
> https://www.ietf.org/archive/id/draft-reddy-dnsop-error-page-05.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page
> Htmlized:
> https://tools.ietf.org/html/draft-reddy-dnsop-error-page-05
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-reddy-dnsop-error-page-05
>
> Abstract:
>When a DNS server filters a query, the response conveys no detailed
>explanation of why that query was blocked, leading thus to end-user
>confusion.  A solution is needed to enhance the user experience.
>
>This document defines a method to return an URI that explains the
>reason why a DNS query was filtered.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> ___
> DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-05.txt

[Joey S]

  
  
Dear Tirumal, dnsop,

Following up on the last IETF session and observations regarding the
usability of this draft at the end of the meeting, this draft covers
2 important areas from my perspective: DNS error information made
available to the end-users as opposed to (mainly)
administrators/operators from the extended-DNS-errors RFC (rfc8914);
the promotion of increased DNS security as a means to achieve
reliable information.

For those two reasons I'd like to ask:

  Are there specific sections of the I-D that require input?
  Are there remaining questions from the 109 meeting?
  What's currently needed for potentially moving forward with WG
adoption?

Thank you,

--
Joey Salazar
Digital Sr. Programme Officer
ARTICLE 19
6E9C 95E5 5BED 9413 5D08 55D5 0A40 4136 0DF0 1A91
On 14-Oct-20 10:50 PM, tirumal reddy
  wrote:


  
  Hi all,

This revision https://tools.ietf.org/html/draft-reddy-dnsop-error-page-05
updates security considerations section to address comments from
the WG during the presentation at IETF-108. 

As a reminder, it discusses a method to return an URL that
explains the reason the DNS query was filtered. It defines an
Error page URI EDNS0 option to return an URI Template which when
accessed provides the reason the DNS query was filtered. The
Error Page URI Template is protected with a signature for data
origin authentication. It discusses mandatory rules (e.g., DoH
and strict privacy profile in DoT) to process the Error page URI
EDNS0 option.

Further comments and suggestions are welcome.

Cheers,
-Tiru

  

  

  -- Forwarded
message -
From: 
Date: Wed, 14 Oct 2020 at 11:25
Subject: New Version Notification for
draft-reddy-dnsop-error-page-05.txt
To: Tirumaleswar Reddy.K ,
Mohamed Boucadair ,
Neil Cook ,
Dan Wing 
  
  
  
  
  A new version of I-D,
  draft-reddy-dnsop-error-page-05.txt
  has been successfully submitted by Tirumaleswar Reddy
  and posted to the
  IETF repository.
  
  Name:           draft-reddy-dnsop-error-page
  Revision:       05
  Title:          DNS Access Denied Error page
  Document date:  2020-10-13
  Group:          Individual Submission
  Pages:          16
  URL:            https://www.ietf.org/archive/id/draft-reddy-dnsop-error-page-05.txt
  Status:         https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
  Htmlized:       https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page
  Htmlized:       https://tools.ietf.org/html/draft-reddy-dnsop-error-page-05
  Diff:           https://www.ietf.org/rfcdiff?url2=draft-reddy-dnsop-error-page-05
  
  Abstract:
     When a DNS server filters a query, the response
  conveys no detailed
     explanation of why that query was blocked, leading
  thus to end-user
     confusion.  A solution is needed to enhance the
  user experience.
  
     This document defines a method to return an URI
  that explains the
     reason why a DNS query was filtered.
  
  
  
  
  Please note that it may take a couple of minutes from
  the time of submission
  until the htmlized version and diff are available at tools.ietf.org.
  
  The IETF Secretariat
  
  

  

  

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



  




OpenPGP_signature
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-05.txt

[tirumal reddy]

Hi all,

This revision https://tools.ietf.org/html/draft-reddy-dnsop-error-page-05
updates security considerations section to address comments from the WG
during the presentation at IETF-108.

As a reminder, it discusses a method to return an URL that explains the
reason the DNS query was filtered. It defines an Error page URI EDNS0
option to return an URI Template which when accessed provides the reason
the DNS query was filtered. The Error Page URI Template is protected with a
signature for data origin authentication. It discusses mandatory rules
(e.g., DoH and strict privacy profile in DoT) to process the Error page URI
EDNS0 option.

Further comments and suggestions are welcome.

Cheers,
-Tiru

-- Forwarded message -
From: 
Date: Wed, 14 Oct 2020 at 11:25
Subject: New Version Notification for draft-reddy-dnsop-error-page-05.txt
To: Tirumaleswar Reddy.K , Mohamed Boucadair <
mohamed.boucad...@orange.com>, Neil Cook , Dan Wing




A new version of I-D, draft-reddy-dnsop-error-page-05.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-dnsop-error-page
Revision:   05
Title:  DNS Access Denied Error page
Document date:  2020-10-13
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/archive/id/draft-reddy-dnsop-error-page-05.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page
Htmlized:   https://tools.ietf.org/html/draft-reddy-dnsop-error-page-05
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-dnsop-error-page-05

Abstract:
   When a DNS server filters a query, the response conveys no detailed
   explanation of why that query was blocked, leading thus to end-user
   confusion.  A solution is needed to enhance the user experience.

   This document defines a method to return an URI that explains the
   reason why a DNS query was filtered.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]

[Peter van Dijk]

Hello Paul,

On Fri, 2020-09-25 at 17:13 -0400, Paul Wouters wrote:
> I could see a use of publishing a DNSKEY at the parent in a DS record
> that could be used for encrypted connections towards child nameservers.

Me too! :-)

> But we talked about this within the context of your other proposals,
> and the view of a number of people and some large operators was that
> this encryption is a per-nameserver thing, and not a per-zone thing.

Lacking defined use cases and alternative proposals, I'm still
considering the possible future where we have one method for each of
those focuses, with different tradeoffs.

> Another item not covered here we talked about before, is that child
> data published in the parent MUST have cryptographic confirmation at
> the child. Or else parents can coerce child data.

Yes, I'm aware! I wanted to keep the -00 simple to first test for
appetite in the WG.

One of the DOTPIN co-authors brought up your 'child confirmation' idea
for both drafts I posted this week, and in both cases, that seems to be
an addition that could easily work. For this draft, in CDS or CDNSKEY;
for the other draft, either by mandating 'some form of it' for anything
that allocates out of the reserved range, or even by specifying right
now 'odd numbers go in the parent, even numbers go in the child, and
content needs to match'.

However, so far it does not look like any of my drafts have gotten
stuck because of -this- so I'm not inclined to put those words in yet.
After adoption seems like plenty of time to discuss this.

> It seems the setup of this record is geared towards a generic mechanism
> of "child publishes stuff at the parent" which muddles the clear child
> vs parent zone divider we have now. It would need a very strong use
> case, but the other use case offered is "might be handy in the future".

Yes - both drafts are 'this may prevent pain later'. I only have
halfbaked ideas for what you could do with 'non-hashed parent-side
publication of child data' (which both drafts provide): DoH URLs,
signed delegation NS sets (which I consider a prime candidate for
'enabling TLSA in child', but that could be done DOTPIN style instead
of either of these drafts), etc.

> While I agree that DNS infrastructure updates have been extremely slow,
> I do think in recent years it has been much better and is still
> improving. So I am less concerned about anything taking 5 years again.

Now if only we could apply that optimism to operator-registry communications :)

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

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

Re: [DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]

[Paul Wouters]

On Thu, 24 Sep 2020, Ben Schwartz wrote:


I would certainly be concerned about such a scenario, but I don't understand 
how it's relevant to Peter's proposal. 
Couldn't this already be done today, by simply including such a hypothetical "parent 
opinion" record in the glue?

For the scenario you're describing, the present lack of DNSSEC authentication 
would not seem to be an obstacle.


middlewhere (voluntarilly or mandated) would not be able to trust glue
for security decisions. where as they might be able to trust parental
signed data.

Of course, any goverment party can publish a list of directives in their
publications and law books, but if those are technically weak or even
formally unprovable, implementation and enforcement will be impossible.

You can also look at it from the reverse way. If the parent wants to
publish anything about the child, even if it received it from the
child, it can already do so using a prefix in its own zone, eg:

_nohats._parentalguidance.ca.   IN DNSKEY 
_nohats._parentalguidance.ca.   IN DS 
_nohats._parentalguidance.ca.   IN TXT 

No DNS infastructure or protocol changes are required for this.

Paul


On Thu, Sep 24, 2020 at 10:53 PM Paul Wouters  wrote:

  [added hrpc to CC: list]

  On Thu, 24 Sep 2020, Peter van Dijk wrote:

  > When talking to Petr Spacek about this, he came up with the following:
  > -if-, long enough ago, besides DS, a range of RRtype numbers would have
  > been reserved with the same processing rules, i.e. these types live in
  > the -parent- and not on the -child-, then both DSPKI and NS2T could
  > become parent side records through the simple act of requesting an
  > IANA allocation from that special range.

  That is an incredibly dangerous idea. It is basically a wildcard from
  the parent to make claims about the child, that the child cannot
  control. You can imagine many kind of RRTYPEs that be be used, eg:

  ADULT_CONTENT
  POLITICAL_SPEECH
  GOVERNMENT_BLOCKED
  MONITOR_USERS
  GEOGRAPHIC_CONSTRAINT

  Of course, governments can already dictate that ISPs do any of these
  things, but with this proposal you are giving them an awesome censorship
  tool. And anyone not complying to the RFCs implementing these, could be
  in clear violation of the working of the internet and should be punished.

  Letting the parent make arbitrary statements about the DNS child is too
  dangerous a tool to roll out.

  Partially this can be mitigated by making the registry Internet Standard
  Required, but that would put a lot of pressure on IETF and DNSOP later
  on - pressure that is not technical in nature, but political.

  I understand the desire for "if we need the parent to say something
  about the child in the future, we would already have the infrastructure
  running". Indeed, it is a neat idea. But too dangerous.

  Paul

  > Name:           draft-peetterr-dnsop-parent-side-auth-types
  > Revision:       00
  > Title:          Parent-side authoritative DNS records for enhanced 
delegation
  > Document date:  2020-09-24
  > Group:          Individual Submission
  > Pages:          5
  > URL:            
https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt
  > Status:         
https://datatracker.ietf.org/doc/draft-peetterr-dnsop-parent-side-auth-types/
  > Html:           
https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.html
  > Htmlized:       
https://tools.ietf.org/html/draft-peetterr-dnsop-parent-side-auth-types-00

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





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

Re: [DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]

[Paul Wouters]

On Fri, 25 Sep 2020, Peter van Dijk wrote:


in this new episode of 'enabling future innovations that we perhaps
cannot even imagine today', please find below a link to a draft
proposing a DS digest type that does no digesting at all. This allows a
zone owner to publish information in the parent zone and have the
parent sign that data on the owner's behalf.



Abstract:
  The VERBATIM DS Digest is defined as a direct copy of the input data
  without any hashing.


I could see a use of publishing a DNSKEY at the parent in a DS record
that could be used for encrypted connections towards child nameservers.

But we talked about this within the context of your other proposals,
and the view of a number of people and some large operators was that
this encryption is a per-nameserver thing, and not a per-zone thing.

Another item not covered here we talked about before, is that child
data published in the parent MUST have cryptographic confirmation at
the child. Or else parents can coerce child data.

It seems the setup of this record is geared towards a generic mechanism
of "child publishes stuff at the parent" which muddles the clear child
vs parent zone divider we have now. It would need a very strong use
case, but the other use case offered is "might be handy in the future".
While I agree that DNS infrastructure updates have been extremely slow,
I do think in recent years it has been much better and is still
improving. So I am less concerned about anything taking 5 years again.

Paul

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

Re: [DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]

[Tony Finch]

Brian Dickson  wrote:
>
> This doesn't even address the significant challenges of developing a
> method of passing the information from the domain owner (registrant) to
> the parent name server (registry). The current mechanism of EPP, does
> not even accommodate the DNS operator unless the DNS operator is also
> the registrar.

Yes, I was going to say something along these lines.

Tangentially I suppose this is a case where the (common) EPP distinction
between domain objects and host objects might (shock, horror) be useful:
maybe we could in principle allow a DNS operator to manage information
about their servers independently of the domains that they host.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lands End to St Davids Head including the Bristol Channel: Northwest 5 to 7,
veering north 4 to 6. Rough at first in southwest, otherwise slight or
moderate. Showers. Good, occasionally moderate.

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

Re: [DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]

[Brian Dickson]

On Fri, Sep 25, 2020 at 5:36 AM Peter van Dijk 
wrote:

> Hello dnsop,
>
> in this new episode of 'enabling future innovations that we perhaps
> cannot even imagine today', please find below a link to a draft
> proposing a DS digest type that does no digesting at all. This allows a
> zone owner to publish information in the parent zone and have the
> parent sign that data on the owner's behalf.
>

No.

Please read all of rfc5507, and in particular section 5, on why this goes
against IAB guidance,
years of operational and developer experience, and is a horrible, horrible
idea.

Do not overload (re-use) RRTYPEs, period.

Also, beyond the potential use case of having parent-side non-authoritative
data DNSSEC signed,
by using a different RRTYPE for the delegation side of a zone cut, and
having a way of discriminating
glue records (such as A and ) from non-glue equivalents, so that the
parental size of a zone
cut can DNSSEC sign these records, the entire design of the Domain Name
System is built around
the delegation principal, which is that the only place data is
authoritative is below a zone cut.

Having the ability to push data up to the parent side, which is controlled
by the child side, violates
the implied security model of the relationships between zones, which
roughly correspond to the
relationship in the Unix file system of directories, symbolic links, and
mount points. The corresponding
mechanism would be to allow an unprivileged user to "give away" ownership
via the "chown" command,
to a privileged account. This capability was extensively abused in the Unix
world until it was blocked.

Implementing this mechanism in DNS would almost certainly be abused in
similar ways, with the same
end result, of having to disable that mechanism due to abuse. This is
reason enough not to even start
down this road.

I'm happy to provide example use cases, but don't want to distract from the
general model being bad,
by playing whack-a-mole on examples and retorts. (See Warren Kumari's email
signature line about
pants and weasels for why.)

With respect and no offense intended.

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

Re: [DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]

[Brian Dickson]

On Thu, Sep 24, 2020 at 10:58 AM Peter van Dijk 
wrote:

> Hello dnsop,
>
> early 2019, Manu of Facebook proposed the DSPKI record - a parent-side-
> of-the-delegation record to hold a pin for authenticating child-side
> DoT servers. This would be undeployable.
>
> A few months ago, Tim April proposed NS2/NS2T, which looks like it
> would clearly benefit from the ability to publish signed data on the
> parent side of a delegation. This ability seems unlikely today.
>
> Also a few months ago, myself and a few others proposed shoehorning
> certificate hashes into the DS record. The shoehorning (and perhaps
> some other aspects of that proposal) were not well received by
> everybody.
>
> When talking to Petr Spacek about this, he came up with the following:
> -if-, long enough ago, besides DS, a range of RRtype numbers would have
> been reserved with the same processing rules, i.e. these types live in
> the -parent- and not on the -child-, then both DSPKI and NS2T could
> become parent side records through the simple act of requesting an
> IANA allocation from that special range.
>
> Sadly, it is not five years ago today. It is today today. So, here is a
> draft that requests that IANA reserves such a range. Knowledge of that
> range and its DS-like handling can then end up in implementations over
> time. When that has happened at some useful scale, we could do a DSPKI
> experiment. NS2T could explore what benefits come from the ability to
> publish in the parent. And, nobody will have to shoehorn hashed TLS
> certificates into DS records.
>
> This draft is a bit rough; I trust it, and this email, have brought the
> idea across. Editorial comments are welcome via GitHub (link is in the
> draft), or via the WG of course.
>
> Looking forward to your thoughts on this.
>

The motivating use cases to justify this, were flawed in a number of ways.

One of those (IMHO, the biggest flaw) was that the pertinent information in
question
was often an attribute of the name server serving the zone, rather than a
zone attribute.

And, for reasons very similar to the problems in the recent draft on
publishing information
on the authority servers in their zone (draft-pp-dnsop-authinfo), there are
problems
in the mapping relationship from zones to nameserver IPs to physical
servers.

These schemes only work under a small subset of conditions, and as such,
are not
useful as a standardized method. The simplest scenario for a zone, is where
the
zone is managed by the domain owner, served only on name servers run by the
domain
owner, with name server names which are exclusively in the domain in
question.
Any situation that does not fall into that scheme, not only won't work, but
would impose
significant operational challenges in attempting to maintain the suggested
scheme.

This doesn't even address the significant challenges of developing a method
of passing
the information from the domain owner (registrant) to the parent name
server (registry).
The current mechanism of EPP, does not even accommodate the DNS operator
unless
the DNS operator is also the registrar.

This doesn't mean that there isn't interest in some of the related
problems, only that the
solutions that have been discussed, including this one, either won't work,
won't scale,
or can't be deployed.

The lack of a dedicated RRTYPEs for the parent side is thus a moot problem.

I concur with Paul Wouters that these would also be particularly dangerous
and problematic.

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

[DNSOP] [Fwd: New Version Notification for draft-vandijk-dnsop-ds-digest-verbatim-00.txt]

[Peter van Dijk]

Hello dnsop,

in this new episode of 'enabling future innovations that we perhaps
cannot even imagine today', please find below a link to a draft
proposing a DS digest type that does no digesting at all. This allows a
zone owner to publish information in the parent zone and have the
parent sign that data on the owner's behalf.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/


 Forwarded Message 
From: internet-dra...@ietf.org
To: Peter van Dijk 
Subject: [EXT] New Version Notification for draft-vandijk-dnsop-ds-
digest-verbatim-00.txt
Date: Fri, 25 Sep 2020 05:33:07 -0700

A new version of I-D, draft-vandijk-dnsop-ds-digest-verbatim-00.txt
has been successfully submitted by Peter van Dijk and posted to the
IETF repository.

Name:   draft-vandijk-dnsop-ds-digest-verbatim
Revision:   00
Title:  The VERBATIM Digest Algorithm for DS records
Document date:  2020-09-25
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-vandijk-dnsop-ds-digest-verbatim/
Html:   
https://www.ietf.org/id/draft-vandijk-dnsop-ds-digest-verbatim-00.html
Htmlized:   
https://tools.ietf.org/html/draft-vandijk-dnsop-ds-digest-verbatim-00


Abstract:
   The VERBATIM DS Digest is defined as a direct copy of the input data
   without any hashing.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

Re: [DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]

[Paul Wouters]

[added hrpc to CC: list]

On Thu, 24 Sep 2020, Peter van Dijk wrote:


When talking to Petr Spacek about this, he came up with the following:
-if-, long enough ago, besides DS, a range of RRtype numbers would have
been reserved with the same processing rules, i.e. these types live in
the -parent- and not on the -child-, then both DSPKI and NS2T could
become parent side records through the simple act of requesting an
IANA allocation from that special range.


That is an incredibly dangerous idea. It is basically a wildcard from
the parent to make claims about the child, that the child cannot
control. You can imagine many kind of RRTYPEs that be be used, eg:

ADULT_CONTENT
POLITICAL_SPEECH
GOVERNMENT_BLOCKED
MONITOR_USERS
GEOGRAPHIC_CONSTRAINT

Of course, governments can already dictate that ISPs do any of these
things, but with this proposal you are giving them an awesome censorship
tool. And anyone not complying to the RFCs implementing these, could be
in clear violation of the working of the internet and should be punished.

Letting the parent make arbitrary statements about the DNS child is too
dangerous a tool to roll out.

Partially this can be mitigated by making the registry Internet Standard
Required, but that would put a lot of pressure on IETF and DNSOP later
on - pressure that is not technical in nature, but political.

I understand the desire for "if we need the parent to say something
about the child in the future, we would already have the infrastructure
running". Indeed, it is a neat idea. But too dangerous.

Paul


Name:   draft-peetterr-dnsop-parent-side-auth-types
Revision:   00
Title:  Parent-side authoritative DNS records for enhanced delegation
Document date:  2020-09-24
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-peetterr-dnsop-parent-side-auth-types/
Html:   
https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.html
Htmlized:   
https://tools.ietf.org/html/draft-peetterr-dnsop-parent-side-auth-types-00


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

[DNSOP] [Fwd: New Version Notification for draft-peetterr-dnsop-parent-side-auth-types-00.txt]

[Peter van Dijk]

Hello dnsop,

early 2019, Manu of Facebook proposed the DSPKI record - a parent-side-
of-the-delegation record to hold a pin for authenticating child-side
DoT servers. This would be undeployable.

A few months ago, Tim April proposed NS2/NS2T, which looks like it
would clearly benefit from the ability to publish signed data on the
parent side of a delegation. This ability seems unlikely today.

Also a few months ago, myself and a few others proposed shoehorning
certificate hashes into the DS record. The shoehorning (and perhaps
some other aspects of that proposal) were not well received by
everybody.

When talking to Petr Spacek about this, he came up with the following:
-if-, long enough ago, besides DS, a range of RRtype numbers would have
been reserved with the same processing rules, i.e. these types live in
the -parent- and not on the -child-, then both DSPKI and NS2T could
become parent side records through the simple act of requesting an
IANA allocation from that special range.

Sadly, it is not five years ago today. It is today today. So, here is a
draft that requests that IANA reserves such a range. Knowledge of that
range and its DS-like handling can then end up in implementations over
time. When that has happened at some useful scale, we could do a DSPKI
experiment. NS2T could explore what benefits come from the ability to
publish in the parent. And, nobody will have to shoehorn hashed TLS
certificates into DS records.

This draft is a bit rough; I trust it, and this email, have brought the
idea across. Editorial comments are welcome via GitHub (link is in the
draft), or via the WG of course.

Looking forward to your thoughts on this.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

 Forwarded Message 
From: internet-dra...@ietf.org
To: Petr Spacek , Peter van Dijk <
peter.van.d...@powerdns.com>
Subject: [EXT] New Version Notification for draft-peetterr-dnsop-
parent-side-auth-types-00.txt
Date: Thu, 24 Sep 2020 10:49:03 -0700

A new version of I-D, draft-peetterr-dnsop-parent-side-auth-types-00.txt
has been successfully submitted by Peter van Dijk and posted to the
IETF repository.

Name:   draft-peetterr-dnsop-parent-side-auth-types
Revision:   00
Title:  Parent-side authoritative DNS records for enhanced delegation
Document date:  2020-09-24
Group:  Individual Submission
Pages:  5
URL:
https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-peetterr-dnsop-parent-side-auth-types/
Html:   
https://www.ietf.org/id/draft-peetterr-dnsop-parent-side-auth-types-00.html
Htmlized:   
https://tools.ietf.org/html/draft-peetterr-dnsop-parent-side-auth-types-00


Abstract:
   A DNS RRtype numeric range that behaves like DS is reserved.  This
   means: being authoritative on the parent side of a delegation; being
   signed by the parent; being provided along with delegations by the
   parent.  If this document had become an RFC five years ago, deploying
   new types (along the lines of NS2/NS2T, DSPKI or various other
   imagined things like DNS ('signed delegation NS')) would be easier to
   deploy and experiment with today.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

[DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-03.txt

[tirumal reddy]

Hi all,

This revision https://tools.ietf.org/html/draft-reddy-dnsop-error-page-03
addresses
several comments from the WG during the presentation at IETF-108.

Major updates are listed below:

1. Error page URI EDNS0 option to return an URI Template which when
accessed provides the reason the DNS query was filtered.
2. The Error Page URI Template is protected with a signature for data
origin authentication.
3. Mandatory rules (e.g., DoH and strict privacy profile in DoT) to process
the Error page URI EDNS0 option.
4. Updates to security consideration section to discuss threats and
mechanisms to address them.

Further comments and suggestions are welcome.

Cheers,
-Tiru

-- Forwarded message -
From: 
Date: Tue, 25 Aug 2020 at 12:55
Subject: New Version Notification for draft-reddy-dnsop-error-page-03.txt
To: Neil Cook , Dan Wing ,
Tirumaleswar Reddy.K , Mohamed Boucadair <
mohamed.boucad...@orange.com>



A new version of I-D, draft-reddy-dnsop-error-page-03.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-dnsop-error-page
Revision:   03
Title:  DNS Access Denied Error page
Document date:  2020-08-24
Group:  Individual Submission
Pages:  16
URL:
https://www.ietf.org/internet-drafts/draft-reddy-dnsop-error-page-03.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
Htmlized:   https://tools.ietf.org/html/draft-reddy-dnsop-error-page-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-dnsop-error-page-03

Abstract:
   When a DNS server filters a query the response conveys no detailed
   explanation of why the query was blocked, leading to end-user
   confusion.  This document defines a method to return an URI that
   explains the reason the DNS query was filtered.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-schwartz-svcb-dns-00.txt

[Ben Schwartz]

Hi ADD and DPRIVE,

I've noticed three recent drafts that propose to use the SVCB format:
draft-mglt-add-rdp, draft-tapril-ns2, and
draft-pauly-add-resolver-discovery.  These drafts, across multiple
working groups, consider distinct use cases and architectures, but they all
propose using SVCB (in very different ways) to convey information about a
DNS server that supports encrypted transport.

In the interest of harmonizing these proposals, creating a solid
foundation, and separating concerns, I've written a short draft that
specifies _only_ a minimal SVCB mapping for DNS URIs*, and does not address
any specific use case.

I hope this draft can enable each of these proposals to focus more on their
goals, and worry less about the SVCB encoding.  (It also serves as an
interesting test of the SVCB design.)

Please review,
Ben Schwartz

*SVCB is based on URIs like https://, so for a DNS mapping we start with
dns:// URIs.

-- Forwarded message -
From: 
Date: Tue, Aug 4, 2020 at 1:38 PM
Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt
To: Benjamin Schwartz 



A new version of I-D, draft-schwartz-svcb-dns-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:   draft-schwartz-svcb-dns
Revision:   00
Title:  Service Binding Mapping for DNS URIs
Document date:  2020-08-04
Group:  Individual Submission
Pages:  8
URL:
https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-00.txt
Status: https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
Htmlized:   https://tools.ietf.org/html/draft-schwartz-svcb-dns-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns


Abstract:
   The SVCB DNS record type expresses a bound collection of endpoint
   metadata, for use when establishing a connection to a named service.
   DNS itself can be such a service, when the server is identified by a
   hostname in a "dns:" URI.  This document provides the SVCB mapping
   for name-based DNS URIs, allowing DNS servers to indicate support for
   new transport protocols.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-02.txt

[tirumal reddy]

Hi all,

This revison https://tools.ietf.org/html/draft-reddy-dnsop-error-page-02
addresses comments from Wes and Vittorio.
As a reminder, it discusses a method to return an URL that explains the
reason the DNS query was filtered. It is useful for HTTPS enabled domain
names blocked by DNS firewalls in Enterprise and Home networks. The error
page URL is returned along with the "Forged Answer" extended error code
defined in ietf-dnsop-extended-error.

Further comments and suggestions are welcome.

-Tiru

-- Forwarded message -
From: 
Date: Tue, 28 Jul 2020 at 05:20
Subject: New Version Notification for draft-reddy-dnsop-error-page-02.txt
To: Dan Wing , Tirumaleswar Reddy.K <
kond...@gmail.com>, Neil Cook , Mohamed Boucadair <
mohamed.boucad...@orange.com>



A new version of I-D, draft-reddy-dnsop-error-page-02.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:   draft-reddy-dnsop-error-page
Revision:   02
Title:  DNS Access Denied Error page
Document date:  2020-07-27
Group:  Individual Submission
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-reddy-dnsop-error-page-02.txt
Status:
https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
Htmlized:   https://tools.ietf.org/html/draft-reddy-dnsop-error-page-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-dnsop-error-page-02

Abstract:
   When a DNS server filters a query the response conveys no detailed
   explanation of why the query was blocked, leading to end-user
   confusion.  This document defines a method to return an URL that
   explains the reason the DNS query was filtered.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

[tirumal reddy]

Hi Wes,

Please see inline

On Fri, 24 Jul 2020 at 19:49, Wes Hardaker  wrote:

> tirumal reddy  writes:
>
> > This draft https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00
> > discusses a method to return an URL that explains the reason the DNS
> > query was filtered.
>
> Interesting idea.


Thanks.


> A couple of points:
>
> 1) The document doesn't state where the HTTPS record should go.  I
> assume in the additional section (it's not an answer).
>

Yes, will update text.


>
> 2) It doesn't talk about what the name should be for the record.  I
> assume it must match the name that was requested (IE, the question
> section name).
>

Yup, the name of the record must match the original QNAME in the DNS
request; will add clarifying text.


>
> 3) WRT DNSSEC and this statement:
>
>but DNSSEC signing and validation
>is not possible for the HTTPS record returning the error page URL
>along with the "Forged Answer" extended error.
>
>You should probably also insert a MUST / MUST NOT about these errors
>and how they must only come from the resolver the client is talking
>to and must not be forwarded from something upstream (double hops
>provide no trust in DOH (or any other secured transport) without
>DNSSEC or some other signing mechanism)
>

Good point, added following text to security considerations section:

The DNS resolver MUST NOT forward the "Forged Answer" extended error and
the HTTPS record from an upstream resolver as an attacker (e.g., MiTM)
could insert a fake extended error response and HTTPS record into the DNS
response.

Cheers,
-Tiru


>
> --
> Wes Hardaker
> USC/ISI
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

[Wes Hardaker]

tirumal reddy  writes:

> This draft https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00
> discusses a method to return an URL that explains the reason the DNS
> query was filtered.

Interesting idea.  A couple of points:

1) The document doesn't state where the HTTPS record should go.  I
assume in the additional section (it's not an answer).

2) It doesn't talk about what the name should be for the record.  I
assume it must match the name that was requested (IE, the question
section name).

3) WRT DNSSEC and this statement:

   but DNSSEC signing and validation
   is not possible for the HTTPS record returning the error page URL
   along with the "Forged Answer" extended error.

   You should probably also insert a MUST / MUST NOT about these errors
   and how they must only come from the resolver the client is talking
   to and must not be forwarded from something upstream (double hops
   provide no trust in DOH (or any other secured transport) without
   DNSSEC or some other signing mechanism)

-- 
Wes Hardaker
USC/ISI

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

[DNSOP] Fwd: New Version Notification for draft-tapril-ns2-01.txt

[Tim April]

Hello DNSOP,

First, apologies for not sending a note like this to the list with the 
-00 version. I reviewed the thread(s) that happened after the last work 
group webexes right after IETF107 and tried to incorporate the feedback 
from the webex and email threads into the latest revision.


A summary of the changes can be found below and also at the end of the 
draft. The primary areas of focus in this update were to remove the 
“kitchen-sinky” ness of the record, (including the removal of the DS 
information) and then adding more clarity around the uses of the record.


* Removed DS and DNSKEY SvcParamFields. Avoids issues with DNSSEC 
signing in the parent.
* Removed IPv{4,6}Hints SvcParamFields. There was a discussion on DNSOP 
about how glue is required
* Updating when to sign the NS2 / NS2T records (removed signing in the 
parent)
* Attempting to clean up the introduction, goals and motivations of the 
document

* Adding a privacy considerations section
* Adding more clarity around when to include/expect the NS2/NS2T records
* Adding this note that CNS2 will not be included in this draft
* Prohibiting NS2 and NS2T from existing at the same name
* Making the statement about the parent records being glue and should 
not be signed


This document is tracked in a GitHub at https://github.com/timapril/ns2.

Questions, Comments,  Reviews, GitHub Issues & Pull Requests and all 
welcome.


Thank You,

--tim

Forwarded message:


From: internet-dra...@ietf.org
To: Tim April 
Subject: New Version Notification for draft-tapril-ns2-01.txt
Date: Mon, 13 Jul 2020 13:02:57 -0700

A new version of I-D, draft-tapril-ns2-01.txt
has been successfully submitted by Tim April and posted to the
IETF repository.

Name:   draft-tapril-ns2
Revision:   01
Title:  Parameterized Nameserver Delegation with NS2 and NS2T
Document date:  2020-07-13
Group:  Individual Submission
Pages:  20
URL:
https://www.ietf.org/internet-drafts/draft-tapril-ns2-01.txt

Status: https://datatracker.ietf.org/doc/draft-tapril-ns2/
Htmlized:   https://tools.ietf.org/html/draft-tapril-ns2-01
Htmlized:   https://datatracker.ietf.org/doc/html/draft-tapril-ns2
Diff:   https://www.ietf.org/rfcdiff?url2=draft-tapril-ns2-01

Abstract:
   Within the DNS, there is no mechanism for authoritative servers to
   advertise which transport methods they are capable of.  If secure
   transport methods are adopted by authoritative operators, transport
   signaling would be required to negotiate how authoritative servers
   would be contacted by resolvers.  This document provides two new
   Resource Record Types, NS2 and NS2T, to facilitate this negotiation
   by allowing zone owners to signal how the authoritative 
nameserver(s)

   for their zone(s) may accept queries.




Please note that it may take a couple of minutes from the time of 
submission

until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

[tirumal reddy]

On Thu, 9 Jul 2020 at 12:52, Vittorio Bertola <
vittorio.bert...@open-xchange.com> wrote:

>
> Il 09/07/2020 08:53 tirumal reddy  ha scritto:
>
> Regarding section 4, in DPRIVE (on draft bcp-op) we have recently been
> told that the IETF does not recommend in its best practices anything which
> is not strictly technical (in that case, it was about communicating to
> users the jurisdiction under which DNS resolution is provided):
>
>
> https://mailarchive.ietf.org/arch/msg/dns-privacy/rJ7R3OBUyySfEyJgwhoxs1DNGuc/
>
> So I would assume that that section is out of scope as well, and I would
> remove it.
>
>
> My understanding is the "jurisdiction" is out of scope but not RPS (see
> https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-12#section-6)
>
> Sure, those three points were agreed with Alissa as the scope of any
> statement that might be described in the best practice:
>
>o  Relates _only_ to matters around to the technical operation of DNS
>   privacy services, and not on any other matters.
>
>o  Does not attempt to offer an exhaustive list for the contents of
>   an RPS.
>
>o  Is not intended to form the basis of any legal/compliance
>   documentation.
>
> So I would take that as guidance here as well: I don't think we can say
> whether it should contain regulatory information, redress measures etc.
> (though that would indeed be advisable).
>

Yes, I agree; will update the section to say:

   The content of the error page is non-normative, the above text only
   provides the guidelines and template for the error page and.

   o  Does not attempt to offer an exhaustive list for the contents of
  an error page.

   o  It is not intended to form the basis of any legal/compliance for
  developing the error page.

Cheers,
-Tiru

Also, in Italy the ISP, when blocking websites by court order, is required
> to show a page which is exactly defined by law and by the public authority
> that "seized" the website (e.g.
> https://www.startmag.it/wp-content/uploads/butac.png ) - it is not
> allowed to change it in any way. I would expect that to happen in other
> countries as well.
>
> --
>
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> vittorio.bert...@open-xchange.com
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

[Vittorio Bertola]

> Il 09/07/2020 08:53 tirumal reddy  ha scritto:
> 
> 
> > > Regarding section 4, in DPRIVE (on draft bcp-op) we have 
> recently been told that the IETF does not recommend in its best practices 
> anything which is not strictly technical (in that case, it was about 
> communicating to users the jurisdiction under which DNS resolution is 
> provided):
> > 
> > 
> > https://mailarchive.ietf.org/arch/msg/dns-privacy/rJ7R3OBUyySfEyJgwhoxs1DNGuc/
> > 
> > So I would assume that that section is out of scope as well, and I 
> > would remove it.
> > 
> > > 
> My understanding is the "jurisdiction" is out of scope but not RPS (see 
> https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-12#section-6) 
> 
Sure, those three points were agreed with Alissa as the scope of any statement 
that might be described in the best practice:

o  Relates _only_ to matters around to the technical operation of DNS
privacy services, and not on any other matters.

o  Does not attempt to offer an exhaustive list for the contents of
an RPS.

o  Is not intended to form the basis of any legal/compliance
documentation.

So I would take that as guidance here as well: I don't think we can say whether 
it should contain regulatory information, redress measures etc. (though that 
would indeed be advisable). Also, in Italy the ISP, when blocking websites by 
court order, is required to show a page which is exactly defined by law and by 
the public authority that "seized" the website (e.g. 
https://www.startmag.it/wp-content/uploads/butac.png ) - it is not allowed to 
change it in any way. I would expect that to happen in other countries as well.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bert...@open-xchange.com mailto:vittorio.bert...@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Fwd: New Version Notification for draft-reddy-dnsop-error-page-00.txt

[tirumal reddy]

On Wed, 8 Jul 2020 at 18:51, Bob Harold  wrote:

>
> On Wed, Jul 8, 2020 at 3:38 AM tirumal reddy  wrote:
>
>> Hi all,
>>
>> This draft https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00
>> discusses a method to return an URL that explains the reason the DNS query
>> was filtered. It is useful for HTTPS enabled domain names blocked by DNS
>> firewalls for non-managed devices in Enterprise and Home networks. The
>> error page URL is returned along with the "Forged Answer" extended error
>> code defined in ietf-dnsop-extended-error.
>>
>> Comments and suggestions are welcome.
>>
>> Cheers,
>> -Tiru
>>
>> -- Forwarded message -
>> From: 
>> Date: Wed, 8 Jul 2020 at 12:55
>> Subject: New Version Notification for draft-reddy-dnsop-error-page-00.txt
>> To: Dan Wing , Neil Cook ,
>> Tirumaleswar Reddy.K , Mohamed Boucadair <
>> mohamed.boucad...@orange.com>
>>
>>
>>
>> A new version of I-D, draft-reddy-dnsop-error-page-00.txt
>> has been successfully submitted by Tirumaleswar Reddy and posted to the
>> IETF repository.
>>
>> Name:   draft-reddy-dnsop-error-page
>> Revision:   00
>> Title:  DNS Access Denied Error page
>> Document date:  2020-07-08
>> Group:  Individual Submission
>> Pages:  10
>> URL:
>> https://www.ietf.org/internet-drafts/draft-reddy-dnsop-error-page-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-reddy-dnsop-error-page/
>> Htmlized:
>> https://tools.ietf.org/html/draft-reddy-dnsop-error-page-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-reddy-dnsop-error-page
>>
>>
>> Abstract:
>>When a DNS server filters a query the response conveys no detailed
>>explanation of why the query was blocked, leading to end-user
>>confusion.  This document defines a method to return an URL that
>>explains the reason the DNS query was filtered.
>>
>>
> Minor nit:
>
> 7.1.  Error Page URL DNS Parameter
>
>This parameter indicates the URL that provides additional information
>about the cause of blocking access to a domain is designated for use
>with the "Forged answer" extended error code.  This is a string
>encoded as UTF-8 characters.  This is a string encoded as UTF-8 characters.
>
>  -- The last sentence is duplicated (This is a string encoded as UTF-8
> characters.)
>

Thanks, fixed in my local copy.

-Tiru


>
> --
> Bob Harold
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop