Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

[Manu Bretelle]

Hi Roy,

It seems those 2 paragraphs are conflicting with each others:

On the one hand the aggressive use of DNSSEC-validated cache is suggested
for the reporting agent:

```

This caching is essential.  It ensures that the number of reports
   sent by a reporting resolver for the same problem is dampened, i.e.
   once per TTL, however, certain optimizations such as [RFC8020
] and

   [RFC8198 ] may reduce the
number of error reporting queries as well.
```

But on the other hand, it is not recommended to sign the reporting agent domain.

```
A solution is to avoid DNSSEC for the reporting agent domain.
   Signing the agent domain will incur an additional burden on the
   reporting resolver, as it has to validate the response.  However,

   this response has no utility to the reporting resolver.
```

Manu


On Tue, Nov 9, 2021 at 3:07 PM Roy Arends  wrote:

> Dear WG,
>
> After the October 26, IETF DNSOP interim WG on DNS Error Reporting, the
> document editors have made the following changes to reflect the discussion:
>
> Change 1) Due to qname minimisation, the reporting agent may not know that
> the reported string has been shortened. There were a few options suggested,
> such as adding a label counter. However, the most straightforward option
> seemed to be to start the reporting query with an _er label as well.
>
> Change 2) There was an observation by developers that some authoritative
> servers do not parse (unknown) EDNS0 options correctly, leading to an
> additional roundtrip by the resolver. It was suggested that authoritative
> servers could return the new EDNS0 option “unsolicited”. This is already
> the case for Extended DNS errors. We have adopted this suggestion. It was
> also pointed out that this kind of unsolicited behaviour can be surveyed.
> We believe that one such effort is underway.
>
> Change 3) There as a lot of descriptive text what implementations should
> and shouldn’t do, and what configurations should and shouldn’t do. This was
> found to be overly descriptive and pedantic, and has now been removed.
>
> There was a request to put the markdown version of the document in GitHub.
> This has now been placed here:
> https://github.com/RoyArends/draft-ietf-dnsop-dns-error-reporting
>
> New version:
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-error-reporting-01.txt
> Diffs:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-error-reporting-01
>
> Warm regards,
>
> Roy Arends
>
> ___
> 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] I-D Action: draft-ietf-dnsop-dns-error-reporting-01.txt

[Manu Bretelle]

>
>
> B) Variant B:
> - My domain "petrs.example" hosts a really nasty political satire, and
> it gets censored a lot
> - I don't care about reports of EDE "Censored" because there is nothing
> I can do about them anyway
> - I still _do_ care about technical issues.
>
> To make use of the same technique as in the previous example (wildcard),
> we would have to switch order of elements in the reporting query to:
>
> _er..._er.
>
> This structure allows to use the same trick on per-EDE code basis:
>
> $ORIGIN _er.agent.test.
> * TXT "tell me!"
> 16 TXT "silence"  ; 16 = EDE Censored
>
>
>
I was actually wondering how this family of code (specifically 15, 16, and
17) would be handled given that they are "local" policies more than actual
errors in regard to the authoritative name server.
But as an extension, how a resolver would keep tab on what should or should
not be reported.
This is likely an effective way for auth operators to silence what they do
not care about


The question is: Which variant is better?
>
> I don't remember from our previous discussions if the current ordering
> in draft was a conscious choice or not, sorry if I forgot.
>

On a first read I thought this was trading effectively stubbing out EDE
code but losing QNAME level solution, but assuming that non-terminal
wildcard are widely supported (RFC4592 section 2.1.3. [0]), it seems that
we could benefit from both world by silencing domain specific with:

```
$ORIGIN _er.agent.test.
* TXT "tell me!"
dnssec-failed.petrs.example.* TXT "silence this specific domain"
16 TXT "silence this specific code"  ; 16 = EDE Censored
```

There is still the QTYPE to fit somewhere, but it seems the same logic
could apply?

Enjoy the weekend!

Manu

[0] https://datatracker.ietf.org/doc/html/rfc4592#section-2.1.3


>
> Have a great weekend everyone!
>
> --
> Petr Špaček
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Re: Deprecating infrastructure .INT domains

[Kim Davies]

Quoting Masataka Ohta on Friday November 12, 2021:
> 
> > The operational decisions relating to these things have already been
> > made, as I understand it -- the delegations no longer exist. Kim and
> > Amanda's document seems to have two purposes: (1) to document this
> > operational reality, and (2) to update protocol specifications to
> > reflect that operational reality.
> 
> I'm afraid (1) should be documented by a separate rfc maybe titled
> as "Relationship between IETF and IANA", which should clarify
> semantics of "IANA considerations" section of not only this but
> also other rfcs, which was not a problem when both of the rfc
> editor and IANA was the same person.
> 
> Is the "IANA considerations" section just a recommendation from
> IETF/ISOC to IANA/ICANN or approved by IANA/ICANN during *modified*
> standardization process of IETF?

These are fair points and hopefully the language can be tweaked to make
it a little clearer. (RFC 2860 does define the relationship between IETF
and IANA, but the role of .INT was modified as a consequence of RFC
3172)

Most of the names in the draft were in the zone when we started the
inventory process a couple of years ago. For those that were lame
for over a year we removed them from the zone because they were
already functionally inoperable. For the remaining two that are in
there, there doesn't appear to be any sign that they are currently
configured to operate as documented. Specifically, {1..9}.tpc.int and
{0..9,a..f}.nsap.int all return NXDOMAIN.

Even if we are perhaps duly empowered to make such an operational
decision regarding these delegations, producing this draft and gaining
additional consensus on these actions I think will produce a better
result given the original delegations eminated from IETF work.

kim

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

[DNSOP] Fwd: I-D Action: draft-ietf-dnsop-rfc5933-bis-07.txt

[Dmitry Belyavsky]

Dear colleagues,

The updated version of the document is uploaded.
Difference with the previous version is a description of  changes from RFC
5933.

Thanks to Stephane Bortzmeyer.

-- Forwarded message -
From: 
Date: Fri, Nov 12, 2021 at 8:33 PM
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-07.txt
To: 
Cc: 



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations WG of the
IETF.

Title   : Use of GOST 2012 Signature Algorithms in DNSKEY
and RRSIG Resource Records for DNSSEC
Authors : Dmitry Belyavskiy
  Vasily Dolmatov
Filename: draft-ietf-dnsop-rfc5933-bis-07.txt
Pages   : 9
Date: 2021-11-12

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 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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


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

[DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : Use of GOST 2012 Signature Algorithms in DNSKEY and 
RRSIG Resource Records for DNSSEC
Authors : Dmitry Belyavskiy
  Vasily Dolmatov
Filename: draft-ietf-dnsop-rfc5933-bis-07.txt
Pages   : 9
Date: 2021-11-12

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 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[DNSOP] Minutes from IETF112

[Tim Wicinski]

All

Big thanks to Paul Hoffman for pulling all these together.

Where are they? All the usual places:

https://notes.ietf.org/notes-ietf-112-dnsop

https://github.com/ietf-wg-dnsop/wg-materials/blob/main/dnsop-ietf112/dnsop-ietf112-minutes.txt

https://datatracker.ietf.org/meeting/112/materials/minutes-112-dnsop-00

Plus I attached them so nobody has to think hard after this week.

Thanks all. An email with actions will go out next week

Benno/Suzanne/Tim
DNSOP WG at IETF 112
November 11 and 12, 2021
On Meetecho, not in Madrid
Agenda is at https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop
Minutes here only reflect the mic line, not text on the slides

Chairs discussion

Guidance for NSEC3 parameter settings, Wes Hardaker
draft-ietf-dnsop-nsec3-guidance
Ted Lemon: Questions choice of insecure for validating stub resolver
Stub resolver might want to treat >100 as an attack
Wes: Gut reaction is that splitting types will lead to chaos
Precedent is to act like NSEC3 works today
Viktor Dukhovni: When we treat high counts as insecure, every answer 
under that must be treated as insecure
Gap between insecure and SERVFAIL: SERVFAIL allows the zone to 
be treated as secure
Jim Reid: Agrees with Ted, would prefer to respond with SERVFAIL 
instead of insecure at 0 or 1
Ralf Weber: Middleground can cause problems, just have one signal
Wants a hard cut
Wes: Maybe have draft allow sliding toward goal
Petr Špaček: Be strict for zone owners, but allow sliding for validators
Just describe for validators why there are thresholds, but 
don't give values
Describe the properties
Benno Overeinder (as implementer): Agrees with Petr
Thanks Viktor for doing the measurements

DNSSEC automation, Ulrich Wisser
draft-wisser-dnssec-automation
Shumon Huque: Working on the draft has helped get providers to 
implement the key operations part
Will get more progress if this is a WG document
Paul Hoffman: Does this need to be in DNSOP, or maybe a different WG 
that is more operator-specific
Peter Thomassen: If the receiving operator uses a different algorithm, 
there could be protocol implications
Ralf: Thinks this belongs in DNSOP
Viktor: Implementers of nameservers might need to make changes to 
software, so leave it here
Ulrich: Requires complicated state machine in the nameserver to make 
this work
Will have implementation in coming months, testing before IETF 
113

Survey of Domain Verification Techniques using DNS, Shivan Kaul
draft-sahib-domain-verification-techniques
Paul Wouters: This is very important, already a huge problem
Shumon: Current use is quite ad hoc, big security gap
Joey Salazar: Other than a security analysis, what are the next steps?
What has changed since last meeting to support adoption more?
Shivan: Collecting issues
Will add section comparing TXT vs. CNAME
Benno: Discussed how this can fit in with other documents in the queue
Tim Wicinski: Don't stop working on this, it's important
Shumon: Will keep plugging, but want more collaborators
Brett Carr: Supports; suggests that the title be changed to not just be 
about survey
Shivan: Will be more about guidance instead of prescriptive
PeterT: Wonders who the target for the draft is
Wants to be sure the major users are involved in preparing the 
draft
Shumon: Will do outreach to the communities that are already doing this
Ask what would persuade them to adopt this
PaulW and Brett volunteered to help

Structured Data for DNS Access Denied Error Page, Dan Wing
draft-wing-dnsop-structured-dns-error-page
Ben Schwartz: Very cautious about anything that lets the DNS operator 
to jump into a web conversation
There are no safe use case in the web context
Would like a shift to technical use cases and debugging
Could also be used for other DNS failures; an addendum for 
extended error code
Should not be shown to the user to lie or scare them
Jonathan Reed: Sees a use case for debugging and enterprises
Wants an indicator with an NXDOMAIN
Can be in the middle ground between blocking and full access
Could be a signal that "it's not just you"
Andrew Campling: Bad censors work just fine, this helps good censors
Gives visibility to the good cases
Current UI is crap, this gives a better end-user experience in 
enterprises
Eric Orth: It should be scary 
Agrees with Ben
Usable 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-error-reporting-01.txt

[Petr Špaček]

Hello dnsop folks,

Discussion with Manu Bretelle in the other thread got me thinking about 
the subset of codes operators want to hear about. Let's think a bit 
about this part of spec:


On 09. 11. 21 23:59, internet-dra...@ietf.org wrote:

Filename: draft-ietf-dnsop-dns-error-reporting-01.txt
6.1.1.  Constructing the Reporting Query

   The QNAME for the reporting query is constructed by concatenating the
   following elements, appending each successive element in the list to
   the right-hand side of the QNAME:

   o  A label containing the string "_er".

   o  The Extended DNS error, presented as a decimal value, in a single
  DNS label.

   o  The QTYPE that was used in the query that resulted in the extended
  DNS error, presented as a decimal value, in a single DNS label.

   o  The QNAME that was used in the query that resulted in the extended
  DNS error.  The QNAME may consist of multiple labels and is
  concatenated as is, i.e. in DNS wire format.

   o  A label containing the string "_er".

   o  The reporting agent domain.  The reporting agent domain consists
  of multiple labels and is concatenated exactly as received in the
  EDNS option sent by the authoritative server.



4.2.  Example
   _er.7.1.broken.test._er.a01.reporting-agent.example


Using RFC 8020 ("there's nothing below NXDOMAIN") or RFC 8198 (DNSSEC 
aggressive cache) an operator can effectively cut out some parts of the 
"reporting subtree" and dampen queries for it. This enables various 
tricks, depending on how we construct the query name:


_er..._er.
_er..._er.


A) Variant A (current draft):
- I'm operating domain "petrs.example"
- subtree "dnssec-failed.petrs.example" is a playground which 
intentionally fails DNSSEC validation (sorry Manu :-))

- error reporting agent domain is "agent.test"

I use domain dnssec-failed.petrs.example in a piece of Javascript which 
renders "DNSSEC validation does (not) work" text on my web front page 
page, so it gets queried fairly often, and I do not want to hear about 
failures in this subtree.


Within the current draft it can be done with agent.test zone file like this:
$ORIGIN _er.agent.test.
* TXT "tell me!"
dnssec-failed.petrs.example TXT "silence"

Wildcard expansion rules & RFC 8020 & query name minimization will cut 
out the whole subtree, saving traffic and also noise in data received by 
the reporting agent.



B) Variant B:
- My domain "petrs.example" hosts a really nasty political satire, and 
it gets censored a lot
- I don't care about reports of EDE "Censored" because there is nothing 
I can do about them anyway

- I still _do_ care about technical issues.

To make use of the same technique as in the previous example (wildcard), 
we would have to switch order of elements in the reporting query to:


_er..._er.

This structure allows to use the same trick on per-EDE code basis:

$ORIGIN _er.agent.test.
* TXT "tell me!"
16 TXT "silence"  ; 16 = EDE Censored



The question is: Which variant is better?

I don't remember from our previous discussions if the current ordering 
in draft was a conscious choice or not, sorry if I forgot.


Have a great weekend everyone!

--
Petr Špaček

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

Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

[Manu Bretelle]

Hi,

On Fri, Nov 12, 2021 at 5:24 AM Petr Špaček  wrote:

> On 12. 11. 21 7:42, Manu Bretelle wrote:
> > Hi Roy,
> >
> > I like the idea of an out-of-band error reporting and therefore I like
> > the proposition of this draft.
> >
> > One of the things I have a hard time visualizing though is how this
> > could be used for more than reporting DNSSEC specific errors. With the
> > option not being signed in the first place, it does not seem that DNSSEC
> > is a requirement to be able to leverage this functionality, hence it
> > would be great to think how we can make this work for more than
> > DNSSEC-only errors.
>
> E.g. it can conceivably report errors like "resolver had to fallback to
> Nth server because the first one we tried times out". Is that a
> sufficient example?
>

I suppose it could. Another one which may already fit in the EDE error code
could be EDE Code 3, "Stale Answer",
https://www.rfc-editor.org/rfc/rfc8914.html#name-extended-dns-error-code-3-s
as an example.

Some others I have a harder time understanding their value could be EDE
Code 20, "Not Authoritative",
https://www.rfc-editor.org/rfc/rfc8914.html#name-extended-dns-error-code-20-
.
On one hand, this is log you already have as an auth operator, but on the
other hand, through the reporting endpoint, and ignoring possible abuses of
said endpoint, you would get a peek at the resolver view, not just any
unsolicited request that was sent to your auth server, making it easier to
track broken delegation.


> > As it is, the requirement for the EDNS0 option to be in the response,
> > while it does offer some properties such as controlling sampling rate…,
> > essentially will prevent any report of answers which are not properly
> > formatted in the first place, or never received like when a resolver is
> > not able to reach any authorities for a given name, when resolver start
> > falling back on staled data, and possibly in the future, failing to
> > reach over an advertised encrypted channel… There is likely value for an
> > authoritative resolver operator to be able to get report for those
> > issues too.
>
> While I agree with the sentiment that reporting other issues would be
> also useful, I think that _for now_ we should keep the scope limited to
> situations which do not require any extra state in resolvers.
>
> That is, reporting "no server is reachable" requires prior information
> stored or reachable somewhere else, which is IMHO order of magnitude
> more complex task. Let's get experience with simple error reporting
> first and only then move forward to more complex tasks...
>

I am more than happy to have an iterative approach to this. My concern was
that this solution would be the end-goal, essentially closing
possibilities for other type of errors such as the ones mentioned.


>
> > The title of the draft: "DNS Error Reporting" would let one believe that
> > it is a somewhat generic mechanism, but I don't think it is as is.
>
> I disagree here. It is a generic mechanism, see the first response
> paragraph in this e-mail.


This sentence was coming in block with the rest of the paragraph below for
illustration.

>
> > Actually, while DNSSEC is not named in the title/abstract, the examples
> > in the abstract are DNSSEC specific, the wording in the rest of the
> > document refers for the most part to "validating resolvers". Should this
> > be a "DNSSEC Error Reporting" draft? or a "DNS Error Reporting" draft,
> > but then the function of "validating" itself should be less emphasized?
> > While a validating resolver can report more type of errors than a
> > non-validating resolvers, validation is not a requirement to be able to
> > report.
>
> Agreed, but I really don't feel the problem as severe. Would it be
> sufficient to add more examples of non-DNSSEC errors?
>

Yes, I think a non-DNSSEC error could help, along with not using
"validating" outside the scope of DNSSEC specific errors. As an example, in
the terminology, the reporting resolver is a validating resolver:

> Reporting Resolver: In the context of this document, the term
   reporting resolver is used as a shorthand for a validating recursive
   resolver that supports DNS Error Reporting



>
> > On Tue, Nov 9, 2021 at 3:07 PM Roy Arends  > > wrote:
> >
> > Dear WG,
> >
> > Change 3) There as a lot of descriptive text what implementations
> > should and shouldn’t do, and what configurations should and
> > shouldn’t do. This was found to be overly descriptive and pedantic,
> > and has now been removed.
> >
> >
> > I see that the security consideration about not reporting errors from an
> > encrypted channel (over a supposedly unencrypted channel) has been
> > removed. Wouldn’t it make sense to leave it in order to avoid leaking
> > traffic for queries that were not previously visible on the network?
> > Possibly requiring than an encrypted channel (equal or stronger, for
> > whatever definition that may be) is used to send such 

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

[Petr Špaček]

Hello everyone,

let me try to to restart the discussion about "Structured Data for 
Filtered DNS" draft. See below.


On 14. 10. 21 19:36, Dan Wing wrote:
> We recently published -01 of Structured Data for Filtered DNS based 
on WG feedback from IETF 111.  We also incorporated both motivational 
and normative text from draft-reddy-dnsop-error-page.  New version at: 
https://datatracker.ietf.org/doc/html/draft-wing-dnsop-structured-dns-error-page-01


On 10. 11. 21 17:17, Petr Špaček wrote:

Let's start from the hardest questions:

1. Input from browser vendors
-
I believe we really really _really_ need input from end-client vendors, 
most importantly Google Chrome and Safari. Is there any indication that 
they might be interested? If not, why?


In my experience browser people have much better idea about UX design 
and HTTP ecosystem security than we DNS people do, and they might have 
different requirements on the data we plan to send back to clients, or 
reasons why the idea cannot be implemented in browsers as is.


I'm CCing known Google and Mozilla people on this e-mail. Please kindly 
ask Safari people if you know any to contribute here as well.



So, to really start again, I think we need to make step back and ask 
what browsers are willing to work with.


Currently the user experience with any sort of blocking follows.

This is what user sees if:
- blocking is done via forged NXDOMAIN
- the the site has a DNS outage
- there is a typo in the domain name

Chromium:

This site can’t be blockedsite.example’s server IP address could not be found.
Try:
Checking the connection
Checking the proxy, firewall, and DNS configuration
ERR_NAME_NOT_RESOLVED


Firefox:

Hmm. We’re having trouble finding that site.

We can’t connect to the server at blockedsite.example.

If that address is correct, here are three other things you can try:

Try again later.
Check your network connection.
If you are connected but behind a firewall, check that Firefox has 
permission to access the Web.


Safari:

Safari Can't Find the Server
Safari can't open the page "blockedsite.example" because Safari can't find the server 
"blockedsite.example".



This is what happens if blocking is done with forged A RR answer 
pointing to a web server serving "this is blocked" web page:


Chromium:

Your connection is not private
Attackers might be trying to steal your information from blockedsite.example 
(for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID


Firefox:

Warning: Potential Security Risk Ahead

Firefox detected a potential security threat and did not continue to 
blockedsite.example. If you visit this site, attackers could try to steal 
information like your passwords, emails, or credit card details.

What can you do about it?

The issue is most likely with the website, and there is nothing you can do to 
resolve it. You can notify the website’s administrator about the problem.


Safari:

This Connection Is Not Private
This website may be impersonating "blockedsite.example" to steal you personal 
or financial information. You should go back to the previous page.



Finally, The Question for web browser vendors is:
Do you have an interest in improving this user experience?

If the answer is yes, what extra information from the resolver you need?

Thank you for your time.

--
Petr Špaček

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

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

[Petr Špaček]

On 12. 11. 21 15:26, Stephane Bortzmeyer wrote:

On Thu, Nov 11, 2021 at 12:59:42PM +0100,
  Vittorio Bertola  wrote
  a message of 24 lines which said:


I don't want to speak for them (I don't know if they are on this
list, but they definitely are on ADD) but in past discussions around
this concept they recognized its potential usefulness (apart maybe
from a specific browser which seems to have a principle stance
against DNS filters) but were concerned about the security of the
mechanism, i.e. the risk that it could be used to present to the
user a phishing or misleading page,


Moreover, I have serious doubts that DNS configuration errors could be
meaningfully reported to end users. It would be very difficult to make
them understandable and, since we deal with errors in authoritative
servers, the client could not do anything, anyway.

I have nothing against informing users (some will find that useful)
but we should focus on reporting to the zone manager, not to the
client.


Seems like you are talking about a different document? Or are you 
suggesting the document to be dropped entirely because it goes in a 
completely wrong direction?


--
Petr Špaček

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

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

[Ben Schwartz]

On Wed, Nov 10, 2021 at 11:18 AM Petr Špaček  wrote:
...

> 2. If the new option was present in query, then DNS responder sends back
> Extended DNS Errors option (EDE, RFC 8914) with INFO-TEXT field
> formatted according to structured JSON specified in this draft.
>

I like this idea a lot.  In fact, I don't even think we need a new option.
It's not as if INFO-TEXT is already widely used.  We can just declare
something like "if the INFO-TEXT is JSON, here's what it means".

This also allows us to remove the "access denied" emphasis, and broaden our
focus to explaining all kinds of resolution failures.

I also agree that requiring an HTTP URL seems out of place here.  I would
prefer an "ID" string of unspecified contents, so that operators can use
UUIDs, domain names holding TXT records, URIs, or whatever mechanism they
want to identify failure types.


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

Re: [DNSOP] Fwd: I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt

[Dmitry Belyavsky]

Dear Stephane,

On Fri, Nov 12, 2021 at 2:46 PM Stephane Bortzmeyer 
wrote:

> On Fri, Nov 12, 2021 at 01:59:52PM +0100,
>  Dmitry Belyavsky  wrote
>  a message of 153 lines which said:
>
> > New version of the draft is uploaded.
>
> I would like to have to additions, if you have time:
>
> * a section summarizing the changes since RFC 5933. It seems it is
> just GOST R 34.10-2001 replaced by GOST R 34.10-2012?
>

Yes, I will add the corresponding part if it is missing. Both signature and
hash are replaced.


> * an implementation status section (see RFC 7942) listing the
> resolvers that can validate with GOST R 34.10 (Unbound, and BIND, it
> seems) but also a few domain names signed with it (I knew caint.su but
> it apparently disappeared).
>

It's a more complicated question.

We had to write this document because the former hash and signature
algorithms
are deprecated both in Russia and by IETF. Then we have a chicken-and-egg
problem:
we can't sign domains without codepoints for hash and signature algorithms,
we can't get the codepoints without RFC.

I have an implementation in my private fork of LDNS, BTW.

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

Re: [DNSOP] Deprecating infrastructure .INT domains

[Stephane Bortzmeyer]

On Fri, Nov 12, 2021 at 08:46:35AM -0500,
 Joe Abley  wrote 
 a message of 25 lines which said:

> The operational decisions relating to these things have already been
> made, as I understand it -- the delegations no longer exist.

nsap.int and tpc.int still exist.

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

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

[Stephane Bortzmeyer]

On Fri, Nov 12, 2021 at 03:26:04PM +0100,
 Stephane Bortzmeyer  wrote 
 a message of 27 lines which said:

> Moreover, I have serious doubts that DNS configuration errors could be
> meaningfully reported to end users. It would be very difficult to make
> them understandable and, since we deal with errors in authoritative
> servers, the client could not do anything, anyway.
> 
> I have nothing against informing users (some will find that useful)
> but we should focus on reporting to the zone manager, not to the
> client.
> 
> So, I don't think interaction with Web browser's authors is required.

Sorry, please ignore this message, I've mixed up
draft-wing-dnsop-structured-dns-error-page and
draft-ietf-dnsop-dns-error-reporting.

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

Re: [DNSOP] updated to draft-wing-dnsop-structured-dns-error-page-01

[Stephane Bortzmeyer]

On Thu, Nov 11, 2021 at 12:59:42PM +0100,
 Vittorio Bertola  wrote 
 a message of 24 lines which said:

> I don't want to speak for them (I don't know if they are on this
> list, but they definitely are on ADD) but in past discussions around
> this concept they recognized its potential usefulness (apart maybe
> from a specific browser which seems to have a principle stance
> against DNS filters) but were concerned about the security of the
> mechanism, i.e. the risk that it could be used to present to the
> user a phishing or misleading page,

Moreover, I have serious doubts that DNS configuration errors could be
meaningfully reported to end users. It would be very difficult to make
them understandable and, since we deal with errors in authoritative
servers, the client could not do anything, anyway.

I have nothing against informing users (some will find that useful)
but we should focus on reporting to the zone manager, not to the
client.

So, I don't think interaction with Web browser's authors is required.

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

Re: [DNSOP] draft-moura-dnsop-negative-cache-loop

[Stephane Bortzmeyer]

On Mon, Nov 08, 2021 at 08:49:03AM +0100,
 Giovane C. M. Moura  wrote 
 a message of 58 lines which said:

> We wrote a new draft that adds a new requirement to existing solutions:
> recursive resolvers must detect and negative cache problematic (loop)
> records.

I basically agree with Petr Špaček and Ralf Weber. Resource limiting is:

* more general (it also addresses infinite recursion - CVE-2014-8500,
CVE-2014-8602, CVE-2014-8601, not just loops),

* already implemented.

So, I'm not sure we need a new RFC.

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

Re: [DNSOP] Deprecating infrastructure .INT domains

[Masataka Ohta]

Joe Abley wrote:


The operational decisions relating to these things have already been
made, as I understand it -- the delegations no longer exist. Kim and
Amanda's document seems to have two purposes: (1) to document this
operational reality, and (2) to update protocol specifications to
reflect that operational reality.


I'm afraid (1) should be documented by a separate rfc maybe titled
as "Relationship between IETF and IANA", which should clarify
semantics of "IANA considerations" section of not only this but
also other rfcs, which was not a problem when both of the rfc
editor and IANA was the same person.

Is the "IANA considerations" section just a recommendation from
IETF/ISOC to IANA/ICANN or approved by IANA/ICANN during *modified*
standardization process of IETF?

Masataka Ohta

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

Re: [DNSOP] IETF 112 DNSOP WG agenda

[Benno Overeinder]

Dear WG,

We updated the agenda for Session II today.

After the presentation of nsec3 iterations guidance, there was quite a 
bit of relevant discussion in the jabber room.  It seemed like a good 
idea to set aside 15 minutes for today's session to continue the 
discussion, and luckily Wes agreed.


https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-03

Best regards,

Suzanne, Tim and Benno


On 09/11/2021 17:37, Benno Overeinder wrote:
An updated agenda for DNSOP has been published.  We had to swap some 
presentations due to the availability of presenters.


https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-01


Best regards

Suzanne, Tim and Benno


On 03/11/2021 22:37, Benno Overeinder wrote:

All,

The DNSOP WG agenda for IETF 112 has been published, see 
https://datatracker.ietf.org/meeting/112/materials/agenda-112-dnsop-00.


Best regards,

Suzanne
Tim
Benno

___
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] Deprecating infrastructure .INT domains

[Joe Abley]

On Nov 12, 2021, at 08:28, Masataka Ohta  
wrote:

> Kim Davies wrote:
> 
>> Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/
>> It’s a short document, but at its heart we’ve identified the
>> following domains that are referenced in places but seem to be obsolete:
> 
> That's fine. As the decision is made by IANA/ICANN, not IETF, it is
> appropriate that the intended status is not BCP but informational.

The operational decisions relating to these things have already been made, as I 
understand it -- the delegations no longer exist. Kim and Amanda's document 
seems to have two purposes: (1) to document this operational reality, and (2) 
to update protocol specifications to reflect that operational reality.

I don't see a conflict or expect a difficulty, but I don't think decisions 
relating to (2) lie solely with PTI; the IETF ought to have a hand in making 
them, which I think is what Kim and Amanda are trying to facilitate here.

Having said all that I think it's possible that the only domain under INT that 
has been implicated in standards-track documents is IP6.INT, and that was taken 
care of long ago. So I am not arguing with you about Informational, which is 
quite possibly the right thing.


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

Re: [DNSOP] Fwd: I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt

[Stephane Bortzmeyer]

On Fri, Nov 12, 2021 at 01:59:52PM +0100,
 Dmitry Belyavsky  wrote 
 a message of 153 lines which said:

> New version of the draft is uploaded.

I would like to have to additions, if you have time:

* a section summarizing the changes since RFC 5933. It seems it is
just GOST R 34.10-2001 replaced by GOST R 34.10-2012?

* an implementation status section (see RFC 7942) listing the
resolvers that can validate with GOST R 34.10 (Unbound, and BIND, it
seems) but also a few domain names signed with it (I knew caint.su but
it apparently disappeared).

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

Re: [DNSOP] Deprecating infrastructure .INT domains

[Masataka Ohta]

Kim Davies wrote:


Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/

It’s a short document, but at its heart we’ve identified the
following domains that are referenced in places but seem to be obsolete:


That's fine. As the decision is made by IANA/ICANN, not IETF, it is
appropriate that the intended status is not BCP but informational.

But, abstract and introduction should make it explicit that it
is decided by IANA and/or ICANN. Merely stating "IANA shall" in
latter IANA considerations is too late and should confuse most
readers.

Masataka Ohta

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

Re: [DNSOP] Status of draft-ietf-dnsop-dns-error-reporting

[Petr Špaček]

On 12. 11. 21 7:42, Manu Bretelle wrote:

Hi Roy,

I like the idea of an out-of-band error reporting and therefore I like 
the proposition of this draft.


One of the things I have a hard time visualizing though is how this 
could be used for more than reporting DNSSEC specific errors. With the 
option not being signed in the first place, it does not seem that DNSSEC 
is a requirement to be able to leverage this functionality, hence it 
would be great to think how we can make this work for more than 
DNSSEC-only errors.


E.g. it can conceivably report errors like "resolver had to fallback to 
Nth server because the first one we tried times out". Is that a 
sufficient example?



As it is, the requirement for the EDNS0 option to be in the response, 
while it does offer some properties such as controlling sampling rate…, 
essentially will prevent any report of answers which are not properly 
formatted in the first place, or never received like when a resolver is 
not able to reach any authorities for a given name, when resolver start 
falling back on staled data, and possibly in the future, failing to 
reach over an advertised encrypted channel… There is likely value for an 
authoritative resolver operator to be able to get report for those 
issues too.


While I agree with the sentiment that reporting other issues would be 
also useful, I think that _for now_ we should keep the scope limited to 
situations which do not require any extra state in resolvers.


That is, reporting "no server is reachable" requires prior information 
stored or reachable somewhere else, which is IMHO order of magnitude 
more complex task. Let's get experience with simple error reporting 
first and only then move forward to more complex tasks...



The title of the draft: "DNS Error Reporting" would let one believe that 
it is a somewhat generic mechanism, but I don't think it is as is. 


I disagree here. It is a generic mechanism, see the first response 
paragraph in this e-mail.


Actually, while DNSSEC is not named in the title/abstract, the examples 
in the abstract are DNSSEC specific, the wording in the rest of the 
document refers for the most part to "validating resolvers". Should this 
be a "DNSSEC Error Reporting" draft? or a "DNS Error Reporting" draft, 
but then the function of "validating" itself should be less emphasized? 
While a validating resolver can report more type of errors than a 
non-validating resolvers, validation is not a requirement to be able to 
report.


Agreed, but I really don't feel the problem as severe. Would it be 
sufficient to add more examples of non-DNSSEC errors?



On Tue, Nov 9, 2021 at 3:07 PM Roy Arends > wrote:


Dear WG,

Change 3) There as a lot of descriptive text what implementations
should and shouldn’t do, and what configurations should and
shouldn’t do. This was found to be overly descriptive and pedantic,
and has now been removed.


I see that the security consideration about not reporting errors from an 
encrypted channel (over a supposedly unencrypted channel) has been 
removed. Wouldn’t it make sense to leave it in order to avoid leaking 
traffic for queries that were not previously visible on the network? 
Possibly requiring than an encrypted channel (equal or stronger, for 
whatever definition that may be) is used to send such reports if needed? 
This would also make sure the mechanism is going to work once the ADo* 
mechanisms are ironed out.


AFAIK it was removed because the only things we could place there were 
extremely vague and probably not implementable anyway.


Reason: There is _no such thing_ as 1:1 mapping between client queries 
and outgoing answers, which makes it super hard to define anything sensible.


A simple example:

1. Client A asks for
login.secret.facebook.com
over plain UDP (and is now waiting for resolver's answer).

2. Resolver starts recursing and eventually sends query for 
secret.facebook.com NS over UDP (client sent query over plain UDP, 
right?). At this point the query was sent but answer was not received yet


3. Client B asks for
supersecretdomainnobodyshouldsee.secret.facebook.com
over TLS

4. Resolver deduplicates the query for secret.facebook.com NS, i.e. 
queries (1) and (3) are now waiting for the same packet - delegation 
from facebook.com to secret.facebook.com.


5. If this deduplicated query for secret.facebook.com NS failed and came 
back with error reporting option, what should the resolver do now? We 
have two clients waiting for it. Is the query considered "secret" or 
not? If the client B (packet in step 3.) arrived couple ms later it 
would not be secret?


In short: This way madness lies.

The only sane way to implement "never leak queries to plaintext" policy 
is to operate TLS-only resolver and do not permit non-TLS 
clients/queries. Then you can disable the error reporting feature 
completely ...



Having said that, we can have _some_ text in Security considerations 

Re: [DNSOP] Deprecating infrastructure .INT domains

[Tim Wicinski]

I agree with Petr here.

On Fri, Nov 12, 2021 at 7:56 AM Petr Špaček  wrote:

> On 11. 11. 21 17:56, Joe Abley wrote:
> > Hi Kim,
> >
> > I like the idea of cleaning this up.
> >
> > Choosing nsap.int as an example, I think it would be useful to either
> update RFC 1706 to make it clear that the advice in section 6 of that
> document no longer applies, and that no reverse mapping for NSAP is
> provided in the DNS. I don't think this is a great operational necessity
> since I imagine the number of people who expect this to work is
> approximately zero but it seems good to be tidy.
> >
> > [I'd suggest reclassifying 1706 to historic but that'd also affect the
> specification for the NSAP RRType; maybe that's a good idea too, but it
> seems outside the scope of what you are trying to achieve, and I don't know
> how we would confirm that it's a good idea.]
> >
> > Similar comment for other domains where there's similar existing advice.
>
> FTR I can't see any problems with that, and suggest to do that in one go
> in this document. We have enough RFCs already and wasting more numbers
> (and work) on simple deprecation does not sound useful to me.
>
> Petr Špaček
>
>
> >
> > Happy to offer actual text if that seems useful.
> >
> >
> > Joe
> >
> >> On 11 Nov 2021, at 11:38, Kim Davies  wrote:
> >>
> >> Colleagues,
> >>
> >> I wanted to draw your attention to an Internet Draft we’ve developed,
> >> its goal is to formally deprecate a number of historic “.int”
> >> domains that were designated for Internet infrastructure purposes
> >> decades ago and appear for all intents and purposes obsolete. After some
> >> limited consultation on developing the approach so far, it would be
> >> useful to get some additional eyes on it so we have greater confidence
> >> there is nothing we’ve missed.
> >>
> >> Datatracker link:
> https://datatracker.ietf.org/doc/draft-davies-int-historic/
> >>
> >> It’s a short document, but at its heart we’ve identified the
> >> following domains that are referenced in places but seem to be obsolete:
> >>
> >>  atma.int, ip4.int, nsap.int, rdi.int, reg.int, tpc.int
> >>
> >> Most of these are not delegated in the int zone any longer, but there
> >> are lingering references to them.
> >>
> >> Thanks in advance for any insight, and apologies if you get this message
> >> in duplicate,
>
> ___
> 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: I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt

[Dmitry Belyavsky]

Dear colleagues,

New version of the draft is uploaded.
The only difference from previous is some nits, many thanks Tim Wicinski
for the nitpicking.

-- Forwarded message -
From: 
Date: Fri, Nov 12, 2021 at 1:57 PM
Subject: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt
To: 
Cc: 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Domain Name System Operations WG of the
IETF.

Title   : Use of GOST 2012 Signature Algorithms in DNSKEY
and RRSIG Resource Records for DNSSEC
Authors : Dmitry Belyavskiy
  Vasily Dolmatov
Filename: draft-ietf-dnsop-rfc5933-bis-06.txt
Pages   : 9
Date: 2021-11-12

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 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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


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

[DNSOP] I-D Action: draft-ietf-dnsop-rfc5933-bis-06.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

Title   : Use of GOST 2012 Signature Algorithms in DNSKEY and 
RRSIG Resource Records for DNSSEC
Authors : Dmitry Belyavskiy
  Vasily Dolmatov
Filename: draft-ietf-dnsop-rfc5933-bis-06.txt
Pages   : 9
Date: 2021-11-12

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 datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5933-bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5933-bis-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5933-bis-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

Re: [DNSOP] Deprecating infrastructure .INT domains

[Petr Špaček]

On 11. 11. 21 17:56, Joe Abley wrote:

Hi Kim,

I like the idea of cleaning this up.

Choosing nsap.int as an example, I think it would be useful to either update 
RFC 1706 to make it clear that the advice in section 6 of that document no 
longer applies, and that no reverse mapping for NSAP is provided in the DNS. I 
don't think this is a great operational necessity since I imagine the number of 
people who expect this to work is approximately zero but it seems good to be 
tidy.

[I'd suggest reclassifying 1706 to historic but that'd also affect the 
specification for the NSAP RRType; maybe that's a good idea too, but it seems 
outside the scope of what you are trying to achieve, and I don't know how we 
would confirm that it's a good idea.]

Similar comment for other domains where there's similar existing advice.


FTR I can't see any problems with that, and suggest to do that in one go 
in this document. We have enough RFCs already and wasting more numbers 
(and work) on simple deprecation does not sound useful to me.


Petr Špaček




Happy to offer actual text if that seems useful.


Joe


On 11 Nov 2021, at 11:38, Kim Davies  wrote:

Colleagues,

I wanted to draw your attention to an Internet Draft we’ve developed,
its goal is to formally deprecate a number of historic “.int”
domains that were designated for Internet infrastructure purposes
decades ago and appear for all intents and purposes obsolete. After some
limited consultation on developing the approach so far, it would be
useful to get some additional eyes on it so we have greater confidence
there is nothing we’ve missed.

Datatracker link: https://datatracker.ietf.org/doc/draft-davies-int-historic/

It’s a short document, but at its heart we’ve identified the
following domains that are referenced in places but seem to be obsolete:

 atma.int, ip4.int, nsap.int, rdi.int, reg.int, tpc.int

Most of these are not delegated in the int zone any longer, but there
are lingering references to them.

Thanks in advance for any insight, and apologies if you get this message
in duplicate,


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