Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

[Manu Bretelle]

n by the remote side when connecting, but it isn’t something
> enforceable, hence just a complication in the configuration of the server
> and communication path.  (Misanthropically speaking: …as annoying as the
> dozens of happy birthday messages in the intra-office chat channel that
> happen weekly, interrupting any chain of thought one might have had!)
>

It is more about giving the ability to the auth operator to enable other
protocol without shooting themselves in the foot. Yes, until other
transports are not closed, nothing will prevent a resolver from using them,
but this is not what is being solved here. And the one that probably cares
more about the private link is likely the resolver more than then auth
server. It is the one making queries.

If you look back at DNSSEC, had it been possible to turn DNSSEC in
"permissive" mode, would more operators have taken the leap to enable it
knowing that resolvers that would validate records would have been willing
to fallback while the flag is on? I think from an operational point of
view, this is something that can be of great help to build operational
confidence and expertise without taking the risk to break one's DNS.

Manu


>
>
> *From: *Ben Schwartz 
> *Date: *Monday, February 12, 2024 at 16:39
> *To: *Manu Bretelle , Peter Thomassen 
> *Cc: *Edward Lewis , "dnsop@ietf.org" <
> dnsop@ietf.org>
> *Subject: *Re: [DNSOP] [Ext] Re: General comment about downgrades vs.
> setting expectations in protocol definitions
>
>
>
> Manu and I have now published a draft describing this "testing" flag: 
> https://datatracker.ietf.org/doc/draft-manuben-svcb-testing-flag/
> [datatracker.ietf.org]
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-manuben-svcb-testing-flag/__;!!PtGJab4!8-ys4ugbv5zdMQkk3MZf2Nj75pZ-yo7WYmpRUUcFYqy8o3WthsNYI-Tjj_lEwF7T8nK17pWWAF1muSZ9A4M4Qw$>
>
>
>
> While we think this is relevant to DELEG, it is entirely independent and
> could be used in any SVCB setting (although it doesn't have any obvious
> utility for HTTPS records at present).
>
>
>
> --Ben Schwartz
> --
>
> *From:* Manu Bretelle 
> *Sent:* Wednesday, February 7, 2024 2:19 PM
> *To:* Peter Thomassen 
> *Cc:* Edward Lewis ; Ben Schwartz ;
> dnsop@ietf.org 
> *Subject:* Re: [DNSOP] [Ext] Re: General comment about downgrades vs.
> setting expectations in protocol definitions
>
>
>
> On Thu, Feb 1, 2024 at 4: 49 AM Peter Thomassen  wrote:
> On 2/1/24 13: 34, Edward Lewis wrote: > The proper response will depend on
> the reason - more accurately the presumed (lacking any out-of-band signals)
> reason - why
>
> ZjQcmQRYFpfptBannerStart
>
> *This Message Is From an External Sender *
>
>
>
> ZjQcmQRYFpfptBannerEnd
>
>
>
>
>
> On Thu, Feb 1, 2024 at 4:49 AM Peter Thomassen  wrote:
>
>
>
> On 2/1/24 13:34, Edward Lewis wrote:
> > The proper response will depend on the reason - more accurately the
> presumed (lacking any out-of-band signals) reason - why the record is
> absent.
>
> Barring any other information, the proper response should IMHO not depend
> on the presumed reason, but assume the worst case. Anything else would
> break expected security guarantees.
>
>
>
> Agreed, I don't think that the protocol should prescribe what to do in
> case of "operational error". Differentiating an "operational error" from an
> actual malicious interference is very likely going to be a slippery slope.
> That being said, I think it will be useful for adoption that resolvers
> provide a feature to use DELEG and fallback to NS when things are not
> correct. This is not something that is to be part of the protocol though.
>
>
>
> What I see could be useful is if we could signal something alike the
> qualifier in SPF [0]. This way an operator could onboard their zone into
> DELEG in "testing mode", allowing them to enable DELEG with the comfort of
> falling back to NS, build confidence and flip the switch. This could have
> the side effect of ever having DELEG delegations in "testing mode" though.
>
>
>
>
>
> [0] https://www.spf-record.com/syntax [spf-record.com]
> <https://urldefense.com/v3/__https:/www.spf-record.com/syntax__;!!PtGJab4!8-ys4ugbv5zdMQkk3MZf2Nj75pZ-yo7WYmpRUUcFYqy8o3WthsNYI-Tjj_lEwF7T8nK17pWWAF1muSaTtQQjeA$>
>
>
>
> Manu
>
>
>
>
>
>
>
> > From observations of the deployment of DNSSEC, [...]
> > It’s very important that a secured protocol be able to thwart or limit
> damage due to malicious behavior, but it also needs to tolerate benign
> operational mistakes.  If mistakes are frequent and addressed by dropping
> t

Re: [DNSOP] [Ext] Re: General comment about downgrades vs. setting expectations in protocol definitions

[Manu Bretelle]

On Thu, Feb 1, 2024 at 4:49 AM Peter Thomassen  wrote:

>
>
> On 2/1/24 13:34, Edward Lewis wrote:
> > The proper response will depend on the reason - more accurately the
> presumed (lacking any out-of-band signals) reason - why the record is
> absent.
>
> Barring any other information, the proper response should IMHO not depend
> on the presumed reason, but assume the worst case. Anything else would
> break expected security guarantees.
>
>
Agreed, I don't think that the protocol should prescribe what to do in case
of "operational error". Differentiating an "operational error" from an
actual malicious interference is very likely going to be a slippery slope.
That being said, I think it will be useful for adoption that resolvers
provide a feature to use DELEG and fallback to NS when things are not
correct. This is not something that is to be part of the protocol though.

What I see could be useful is if we could signal something alike the
qualifier in SPF [0]. This way an operator could onboard their zone into
DELEG in "testing mode", allowing them to enable DELEG with the comfort of
falling back to NS, build confidence and flip the switch. This could have
the side effect of ever having DELEG delegations in "testing mode" though.


[0] https://www.spf-record.com/syntax

Manu




> > From observations of the deployment of DNSSEC, [...]
> > It’s very important that a secured protocol be able to thwart or limit
> damage due to malicious behavior, but it also needs to tolerate benign
> operational mistakes.  If mistakes are frequent and addressed by dropping
> the guard, then the security system is a wasted in investment.
>
> That latter sentence seems right to me, but it doesn't follow that the
> protocol needs to tolerate "benign operational mistakes".
>
> Another approach would be to accompany protocol deployment with a suitable
> set of automation tools, so that the chance of operational mistakes goes
> down. That would be my main take-away from DNSSEC observations.
>
> In other words, perhaps we should consider a protocol incomplete if the
> spec doesn't easily accommodate automation and deployment without it would
> yield significant operational risk.
>
> Let's try to include automation aspects from the beginning.
>
> Peter
>
> --
> https://desec.io/
>
> ___
> 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] NOTIFY: How to locate the target

[Manu Bretelle]

On Thu, Nov 9, 2023 at 4:28 PM George Michaelson  wrote:

> I think we're conflating how you learn what endpoint to send NOTIFY
> to, with the protocol extensions or changes to make it legal/normal to
> do NOTIFY for this purpose.


Agreed.


>
> I don't personally think the whole "but how do I know where to do it"
> is as important as some of you seem to think it is. But, having the
> definition of this use of NOTIFY wired down for its protocol elements
> and behaviours, I think thats important.


I think there is essentially 2 pieces to this which should be different
document.

1) how do I find a service provided to the children by the parent, your
WHERE, which is probably something that can be agreed upon without too much
controversy.

2) the protocol to convey that service, your HOW, which will likely get
more diverse opinions as to how to achieve this, and will also need to be
more scrutinize.

DS update is such protocol amongst possibly many (nameserver update, glue
update, ttl updates to name a few).

Manu

>
>
> I fully expect the actual endpoint to be OOB. I don't think it has to
> be in band but I don't mind if there is an RR which handles in-band,
> but to me that isn't the main point: the main point is knowing its a
> general expectation I can do this to parent/publisher when I need to,
> and what protocol it looks like.
>
> Maybe I am missing the point. Sure, CDS was all about in-band, but to
> me, NOTIFY is mechanistically about a HOW not a WHERE. HOW do I format
> records to make a push event happen. WHERE is between me and my
> parent.
>
> -G
>
> ___
> 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] Isolated-networks

[Manu Bretelle]

On Thu, Nov 9, 2023 at 10:21 AM Marc Blanchet 
wrote:

> Hello,
>  I presented draft-many-dnsop-dns-isolated-networks Tuesday at the end of
> dnsop meeting. Thanks for letting me present. Wanted to come back to a few
> points raised.
>
> - About use cases, I see the dnsop Zulip chat that some people were
> interested in the topic, noting about additional use cases (antarctic for
> example). I guess I did not touched enough on this because of limited time,
> but there are many « mostly isolated, often unconnected » networks use
> cases being discussed in various wgs. I think the best place to see those
> are in the Time-Varying Routing wg requirements and use cases documents
> (draft-ietf-tvr-requirements, draft-ietf-tvr-use-cases). Examples such as
> solar energy powered networks, power savings networks, remote networks,
> many are the resource constrained networks where connectivity is not
> permanent, others having dynamic reachability. These drafts were not
> written for the purpose of DNS, but routing, but they all applied almost as
> is to the need of what is discussed in the isolated-networks draft.
> - local names: as these networks are in fact sometimes connected
> (sometimes meaning more than exceptional), names need to be global so that
> both networks are able to resolve names. Local scope names may be in
> addition to global names, but not a replacement.
> - while some use cases like deepspace will take time to be deployed, those
> organizations involved are planning years ahead and need stable technical
> references that are used as requirements to vendors, RFPs, designs, etc….
> In fact, it is useful now. Some other use cases could benefit it right away
> for implementing.
>

I feel it is hard to provide generic solutions without knowing the actual
requirements, and solutions can widely vary depending on those
requirements. Are the "isolated network" actually stable on the other side?
or can they also be subject to poor network quality? Are the lion share of
queries internal to that possibly isolated network, or external connections
are quite prevalent? Are we talking about operators trying to access
resources, or machines needing to talk to each other? For the latter they
can be a case where one may want to avoid the extra dependency on DNS
because then you have a critical system in a hard to access environment
that possibly relies on an extra piece of infrastructure to be operational
to operate.

That being said, it is probably possible to bucket a set of requirement
sets and work from there.

My gut feeling is that whatever is in those remote networks needs to be
self-sufficient to operate, and this probably call for a dedicated
sub-zone/local domain used and served locally and authoritatively in the
remote side with some form of push/zone xfr from the stable network.
If the remote network may occasionally need resources from across the
unreliable link, stale-answers probably go a long way, with a dash of
prefetching to keep things as up-to-date as possible.

TL;DR, IMHO, concrete use-cases requirements should be enumerated before a
solution can be crafted.

Manu



> Regards, Marc.
> ___
> 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] REFER and DELEG and hackathons and Prague

[Manu Bretelle]

On Wed, Nov 8, 2023 at 7:20 PM Joe Abley  wrote:

>
>
> Since I wasn't at the hackathon (and since there is no sign of related
> discussion about this on this list) I assume a lot of the ideas are being
> shared over beer. But if there's a mailing list or something else going on,
> I'd be interested to hear about it. Perhaps other people on this list might
> be interested, too. I heard there might be a DNS-OARC mattermost channel,
> but I can't find it. Perhaps I'm just not very good at mattermost.


Indeed, there is the DELEG-design chat on dns-oarc Mattermost.

More details in the last slide of
https://www.ietf.org/proceedings/118/slides/slides-118-dnsop-hackaton-118-deleg-rr-proposal-00.pdf

Manu

>
>
> Joe
>
> ___
> 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] OARC 42 Call for Presentations

[Manu Bretelle]

OARC 42 will be a two-day hybrid meeting and the dates are *8th and 9th
February 2024,* to be co-located with NANOG 90 in *Charlotte, North
Carolina, USA.*

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

*Operations*: Any operational gotchas, lessons learned from an outage,
details/reasons for a recent outage (how to improve TTR, tooling).
*Deployment*: DNS config management and release process.
*Monitoring*: Log ingestion pipeline, analytics infrastructure, anomaly
detection.
*Scaling*: DNS performance management and metrics. Increasing DNS Server
Efficiency
*Security/Privacy*: DNSSEC signing and validation, key storage, rollovers,
qname minimization, DoH/DoT

The presentations can be either 10 or 20 minutes in length (plus 5 minutes
for Q). Proposals for in-person lightning presentations will be opened closer
to the Workshop dates.

Workshop Milestones:

2023-09-07 Submissions open via Indico
*2023-11-22 Deadline for submission (23:59 UTC)*
2023-11-29 Preliminary list of contributions published
2023-12-13  Full agenda published
2024-01-10 Deadline for slideset submission and Rehearsal
2024-02-08 OARC 42 Workshop - Day1
2024-02-09 OARC 42 Workshop - Day2

The Registration page and details for presentation submission are published
at:
<https://www.dns-oarc.net/oarc42>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission. Example
guidelines for presentation slides:
https://www.grammarly.com/blog/presentation-tips/

Additional information for speakers of OARC 42
your talk will be broadcast live and recorded for future reference
your presentation slides will be available for delegates and others to
download and refer to, before, during and after the meeting
Remote speakers have mandatory rehearsal (Date and Time TBD). It would be
very useful to have your slides (even if draft) ready for this.

Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via submissi...@dns-oarc.net

*Manu Bretelle, for the DNS-OARC Programme Committee*

OARC depends on sponsorship to fund its workshops and associated social
events. Please contact spon...@dns-oarc.net if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 41 - Call for Contribution -- deadline extension

[Manu Bretelle]

Deadline for OARC 41 abstract submission is extended to June 20th, 23:59
UTC.

Please note that, we are looking for contributions and remote participation
is actively supported

*

OARC 41 will be a two-day hybrid meeting and the dates are 6th and 7th
September to be co-located with ICANN DNS Symposium in Da Nang, Vietnam.

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

   - Operations: Any operational gotchas, lessons learned from an outage,
   details/reasons for a recent outage (how to improve TTR, tooling).


   - Deployment: DNS config management and release process.


   - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
   detection.


   - Scaling: DNS performance management and metrics. Increasing DNS Server
   Efficiency


   - Security/Privacy: DNSSEC signing and validation, key storage,
   rollovers, qname minimization, DoH/DoT


The presentations can be either 10 or 20 minutes in length (plus 5 minutes
for Q). Proposals for in-person lightning presentations will be opened at
the Workshop.

Workshop Milestones:

2023-04-16 Submissions open via Indico
2023-06-20 Deadline for submission (23:59 UTC)
2023-06-27 Preliminary list of contributions published
2023-07-11  Full agenda published
2023-08-08 Deadline for slideset submission and Rehearsal
2023-09-06 OARC 41 Workshop - Day1
2023-09-07 OARC 41 Workshop - Day2

The Registration page and details for presentation submission are published
at:
<https://www.dns-oarc.net/oarc41>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
Example guidelines
for presentation slides: https://www.grammarly.com/blog/presentation-tips/

Additional information for speakers of OARC 41

   - your talk will be broadcast live and recorded for future reference


   - your presentation slides will be available for delegates and others to
   download and refer to, before, during and after the meeting


   - Remote speakers have mandatory rehearsal on 2023-08-08 at 14:00 UTC. It
   would be very useful to have your slides (even if draft) ready for this.


Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via submissi...@dns-oarc.net

Manu Bretelle, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events. Please contact spon...@dns-oarc.net if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 41 - Call for Contribution

[Manu Bretelle]

OARC 41 will be a two-day hybrid meeting and the tentative dates are
between 4-8th September to be co-located with ICANN DNS Symposium.in Asia.

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

   - Operations: Any operational gotchas, lessons learned from an outage,
   details/reasons for a recent outage (how to improve TTR, tooling).


   - Deployment: DNS config management and release process.


   - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
   detection.


   - Scaling: DNS performance management and metrics. Increasing DNS Server
   Efficiency


   - Security/Privacy: DNSSEC signing and validation, key storage,
   rollovers, qname minimization, DoH/DoT


The presentations can be either a full-length presentation - 20 mins (+5
mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A)

*Workshop Milestones:*

2023-04-16 Submissions open via Indico
2023-06-10 Deadline for submission (23:59 UTC)
2023-06-27 Preliminary list of contributions published
2023-07-11  Full agenda published
2023-08-08 Deadline for slideset submission and Rehearsal
2023-09-<> OARC 41 Workshop - Day1
2023-09-<> OARC 41 Workshop - Day2

The Registration page and details for presentation submission are published
at:
<https://www.dns-oarc.net/oarc41>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
Example guidelines
for presentation slides: https://www.grammarly.com/blog/presentation-tips/

Additional information for speakers of OARC 41

   - your talk will be broadcast live and recorded for future reference


   - your presentation slides will be available for delegates and others to
   download and refer to, before, during and after the meeting


   - *Remote speakers have mandatory rehearsal on 2023-08-08 at 14:00 UTC.*
   It would be very useful to have your slides (even if draft) ready for this.


Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via submissi...@dns-oarc.net

Manu Bretelle, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events. Please contact spon...@dns-oarc.net if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 40 - Call for Contribution - deadline extension

[Manu Bretelle]

*Deadline for OARC 40 abstract submission is extended to January 5, 23:59
UTC *

Please note that, we are looking for contributions and remote participation
is actively supported



OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in
Atlanta (GA), USA at 10:00 AM  (Local time - EST (UTC-05:00)). The onsite
part of the meeting will be colocated with NANOG 87.

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

   - Operations: Any operational gotchas, lessons learned from an outage,
   details/reasons for a recent outage (how to improve TTR, tooling).
   - Deployment: DNS config management and release process.
   - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
   detection.
   - Scaling: DNS performance management and metrics. Increasing DNS Server
   Efficiency
   - Security/Privacy: DNSSEC signing and validation, key storage,
   rollovers, qname minimization, DoH/DoT


The presentations can be either a full-length presentation - 20 mins (+5
mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A)

*Workshop Milestones:*

2022-10-22 Submissions open via Indico
2022-01-05 Deadline for submission (23:59 UTC)
2023-01-10 Preliminary list of contributions published
2023-01-17 Full agenda published
2023-01-30 Deadline for slideset submission and Rehearsal
2023-02-16 OARC 40 Workshop - Day1
2023-02-17 OARC 40 Workshop - Day2

The Registration page and details for presentation submission are published
at:
<https://www.dns-oarc.net/oarc40>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
Guidelines for presentation slides:
https://www.grammarly.com/blog/presentation-tips/

Additional information for speakers of OARC 40

   - your talk will be broadcast live and recorded for future reference
   - your presentation slides will be available for delegates and others to
   download and refer to, before, during and after the meeting
   - *Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 UTC.*
   It would be very useful to have your slides (even if draft) ready for this.


Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme via submissi...@dns-oarc.net

Manu Bretelle, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events. Please contact spon...@dns-oarc.net if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Reminder OARC 40 - Call for Contribution

[Manu Bretelle]

*Reminder: Deadline for OARC 40 abstract submission - December 20, 23:59
UTC *

Please note that, we are looking for contributions and remote participation
is actively supported



OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in
Atlanta (GA), USA at 10:00 AM  (Local time - EST (UTC-05:00)). The onsite
part of the meeting will be colocated with NANOG 87.

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

   - Operations: Any operational gotchas, lessons learned from an outage,
   details/reasons for a recent outage (how to improve TTR, tooling).


   - Deployment: DNS config management and release process.


   - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
   detection.


   - Scaling: DNS performance management and metrics. Increasing DNS Server
   Efficiency


   - Security/Privacy: DNSSEC signing and validation, key storage,
   rollovers, qname minimization, DoH/DoT


The presentations can be either a full-length presentation - 20 mins (+5
mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A)

*Workshop Milestones:*

2022-10-22 Submissions open via Indico
2022-12-20 Deadline for submission (23:59 UTC)
2023-01-10 Preliminary list of contributions published
2023-01-17 Full agenda published
2023-01-30 Deadline for slideset submission and Rehearsal
2023-02-16 OARC 40 Workshop - Day1
2023-02-17 OARC 40 Workshop - Day2

The Registration page and details for presentation submission are published
at:
<https://www.dns-oarc.net/oarc40>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
Guidelines for presentation slides:
https://www.grammarly.com/blog/presentation-tips/

Additional information for speakers of OARC 40

   - your talk will be broadcast live and recorded for future reference


   - your presentation slides will be available for delegates and others to
   download and refer to, before, during and after the meeting


   - *Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 UTC.*
   It would be very useful to have your slides (even if draft) ready for this.


Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via submissi...@dns-oarc.net

Manu Bretelle, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events. Please contact spon...@dns-oarc.net if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 40 - Call for Contribution

[Manu Bretelle]

OARC 40 will be a two-day hybrid meeting held on 16 & 17 February in
Atlanta (GA), USA at 10:00 AM  (Local time - EST (UTC-05:00)). The onsite
part of the meeting will be colocated with NANOG 87.

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

   - Operations: Any operational gotchas, lessons learned from an outage,
   details/reasons for a recent outage (how to improve TTR, tooling).


   - Deployment: DNS config management and release process.


   - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
   detection.


   - Scaling: DNS performance management and metrics. Increasing DNS Server
   Efficiency


   - Security/Privacy: DNSSEC signing and validation, key storage,
   rollovers, qname minimization, DoH/DoT


The presentations can be either a full-length presentation - 20 mins (+5
mins Q/A) or a lightning presentation - 10 mins (+5 mins for Q/A)

*Workshop Milestones:*

2022-10-22 Submissions open via Indico
2022-12-20 Deadline for submission (23:59 UTC)
2023-01-10 Preliminary list of contributions published
2023-01-17 Full agenda published
2023-01-30 Deadline for slideset submission and Rehearsal
2023-02-16 OARC 40 Workshop - Day1
2023-02-17 OARC 40 Workshop - Day2

The Registration page and details for presentation submission are published
at:
<https://www.dns-oarc.net/oarc40>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.
Guidelines for presentation slides:
https://www.grammarly.com/blog/presentation-tips/

Additional information for speakers of OARC 40

   - your talk will be broadcast live and recorded for future reference


   - your presentation slides will be available for delegates and others to
   download and refer to, before, during and after the meeting


   - *Remote speakers have mandatory rehearsal on 2023-01-31 at 14:00 UTC.*
   It would be very useful to have your slides (even if draft) ready for this.


Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via submissi...@dns-oarc.net

Manu Bretelle, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social
events. Please contact spon...@dns-oarc.net if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 39 - Call for Contribution - deadline extension

[Manu Bretelle]

*Extension: Deadline for OARC 39 abstract submission is extended to
September 13, 23:59 UTC *

Please note:
1) We are looking for contributions and remote participation is actively
supported.
2) OARC 39 will be a joint conference with CENTR and abstract submissions
from CENTR members are welcome.


The abstracts can be submitted using this link:
https://indico.dns-oarc.net/event/44/abstracts/

Thank you,

Manu Bretelle, for the DNS-OARC Programme Committee
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Reminder OARC 39 - Call for Contribution

[Manu Bretelle]

*Reminder: Deadline for OARC 39 abstract submission - September 06, 23:59
UTC *

Please note that, we are looking for contributions and remote participation
is actively supported

---
OARC 39 will be a two-day hybrid meeting held on* 22 & 23 October in
Belgrade, Serbia *at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite
part of the meeting will be *co-located with RIPE** 85.*

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

- Operations: Any operational gotchas, lessons learned from an outage,
details/reasons for a recent outage (how to improve TTR, tooling).
- Deployment:  DNS config management and release process.
- Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
detection.
- Scaling: DNS performance management and metrics. Increasing DNS Server
Efficiency
- Security/Privacy: DNSSEC signing and validation, key storage, rollovers,
qname minimization, DoH/DoT

*Note: OARC 39 will be a joint conference with CENTR and abstract
submissions from CENTR members are welcome.*

As it is a *hybrid *workshop, we'd like to encourage brevity; presentations
should not be longer than 20 minutes (with additional time for questions).

**Workshop Milestones:**

*2022-09-06Deadline for submission (23:59 UTC)*
2022-09-08Preliminary list of contributions published
2022-09-20Full agenda published
2022-10-03Deadline for slideset submission and Rehearsal
2022-10-22OARC 39 Workshop - Day1
2022-10-23OARC 39 Workshop - Day2

The Registration page and details for presentation submission are published
at:
<https://www.dns-oarc.net/oarc39>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers at OARC 39:

* your talk will be broadcast live and recorded for future reference
* your presentation slides will be available for delegates and others to
download and refer to, before, during and after the meeting
* *Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. *It
would be very useful to have your slides (even if draft) ready for this.

*Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.*

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via 

*Manu Bretelle, for the DNS-OARC Programme Committee*

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 39 Call for Contributions

[Manu Bretelle]

OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in
Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The
onsite part of the meeting will be colocated with RIPE 85.

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are
welcome. For inspiration, we provide a non-exhaustive list of ideas:

- Operations: Any operational gotchas, lessons learned from an outage,
details/reasons for a recent outage (how to improve TTR, tooling).
- Deployment: DNS config management and release process.
- Monitoring: Log ingestion pipeline, analytics infrastructure,
anomaly detection.
- Scaling: DNS performance management and metrics. Increasing DNS
Server Efficiency
- Security/Privacy: DNSSEC signing and validation, key storage,
rollovers, qname minimization, DoH/DoT


As it is a hybrid workshop, we'd like to encourage brevity;
presentations should not be longer than 20 minutes (with additional
time for questions).


**Workshop Milestones:**

2022-07-30 Submissions open via Indico
2022-09-06 Deadline for submission (23:59 UTC)
2022-09-08 Preliminary list of contributions published
2022-09-13 Final Contribution list published
2022-09-20 Full agenda published
2022-10-03 Deadline for slideset submission and Rehearsal
2022-10-22 OARC 39 Workshop - Day1
2022-10-23 OARC 39 Workshop - Day2


The Registration page and details for presentation submission are published at:

<https://www.dns-oarc.net/oarc39>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers at OARC 39:

* your talk will be broadcast live and recorded for future reference
* your presentation slides will be available for delegates and others
to download and refer to, before, during and after the meeting
* Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC.
It would be very useful to have your slides (even if draft) ready for
this.

Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at
and/or attend DNS-OARC. More details will be provided when
registration opens.


If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Manu Bretelle, for the DNS-OARC Programme Committee

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

[DNSOP] Reminder OARC 38 - Call for Contribution

[Manu Bretelle]

*Reminder: Deadline for abstract submission - June 20, 23:59 UTC *

*Please note that we are looking for contributions and remote participation
is actively supported.*



OARC38 will be a two-day hybrid meeting held on July 30th and 31st, 2022
starting at 10 am (Eastern). The onsite part of the meeting will be
co-located with IETF 114 (Philadelphia).

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

- Operations: Any operational gotchas, lessons learned from an outage,
details/reasons for a recent outage (how to improve TTR, tooling).
- Deployment:  DNS config management and release process.
- Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
detection.
- Scaling: DNS performance management and metrics. Increasing DNS Server
Efficiency
- Security/Privacy: DNSSEC signing and validation, key storage, rollovers,
qname minimization, DoH/DoT

As it is an *hybrid* workshop, we'd like to encourage brevity;
presentations should not be longer than 20 minutes (with additional time
for questions).

**Workshop Milestones:**
2022-05-01   Submissions open via Indico
2022-06-20Deadline for submission (23:59 UTC)
2022-06-21Initial Contribution list published
2022-06-28Full agenda published
2022-07-12Deadline for slideset submission and Rehearsal
2022-07-30OARC 38 Workshop - Day 1
2022-07-31OARC 38 Workshop - Day 2

The Registration page and details for presentation submission are
published at:https://www.dns-oarc.net/oarc38


To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers of OARC 38:
* your talk will be broadcast live and recorded for future reference
* your presentation slides will be available for delegates and others to
download and refer to, before, during and after the meeting
* *Remote speakers have mandatory rehearsal on 2022-07-12 at*
*15:00 UTC*. It would be very useful to have your slides (even if draft)
ready for this.

*Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.*

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

*, for the DNS-OARC Programme Committee*

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 38 Call for Contributions

[Manu Bretelle]

OARC 38 will be a two-day hybrid meeting held on July 30th and 31st, 2022
starting at 10 am (Eastern)*. *The onsite part of the meeting will be
colocated with IETF 114 (Philadelphia).

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

- Operations: Any operational gotchas, lessons learned from an outage,
details/reasons for a recent outage (how to improve TTR, tooling).
- Deployment:  DNS config management and release process.
- Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
detection.
- Scaling: DNS performance management and metrics. Increasing DNS Server
Efficiency
- Security/Privacy: DNSSEC signing and validation, key storage, rollovers,
qname minimization, DoH/DoT


As it is an *hybrid *workshop, we'd like to encourage brevity;
presentations should not be longer than 20 minutes (with additional time
for questions).


**Workshop Milestones:**

2022-05-01   Submissions open via Indico
2022-06-20Deadline for submission (23:59 UTC)
2022-06-21Initial Contribution list published
2022-06-28Full agenda published
2022-07-12Deadline for slideset submission and Rehearsal
2022-07-30OARC 38 Workshop - Day1
2022-07-31OARC 38 Workshop - Day2


The Registration page and details for presentation submission are published
at:

<https://www.dns-oarc.net/oarc38>

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers of OARC 38

* your talk will be broadcast live and recorded for future reference
* your presentation slides will be available for delegates and others to
download and refer to, before, during and after the meeting
* *Remote speakers* *have mandatory** rehearsal on** 2022-07-12 at 15:00
UTC.* It would be very useful to have your slides (even if draft) ready for
this.

*Note: DNS-OARC provides registration fee waivers for the workshop to
support those who are part of underrepresented groups to speak at and/or
attend DNS-OARC. More details will be provided when registration opens.*


If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

*Manu Bretelle, for the DNS-OARC Programme Committee*

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 37 Schedule is Published

[Manu Bretelle]

Hello friends,

The schedule for OARC 37 is now published and can be viewed here:
https://www.dns-oarc.net/oarc37. Registration is required to be able to
attend. The attendees have an option to attend in-person or online.
In-person attendees please read about the Covid-19 protocol that's
published on the OARC 37 website.

Please remember to sign-up for Mattermost chat <http://chat.dns-oarc.net/> and
join the Workshops channel.

Thank you,

Manu Bretelle
DNS-OARC Programme Committee
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 37 Workshop, Extending Call for Contributions

[Manu Bretelle]

The Program Committee has decided to extend the Call for Contributions
until 17 Jan 2022 23:59 UTC. The OARC Board has decided that OARC 37 will
be a one day hybrid conference.

Thank you if you've already submitted a proposal. We still haven't filled
the capacity and are able to accept more content. Please note that remote
participation is actively supported.

Revised Workshop Milestones:

* 27 December 2021 - Submissions open via Indico
* 17 January 2022 - Deadline for submission (23:59 UTC)
* 19 January 2022 - Initial Contribution list published
* 21 January 2022 - Full agenda published
* 3 February 2022 - Deadline for slideset submission and Rehearsal
* 17 February 2022 - OARC 37 Workshop ( One day conference)

The details for presentation submission are published at the Workshop
website:

https://www.dns-oarc.net/oarc37

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

Manu Bretelle for the DNS-OARC Programme Committee
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] OARC 37 Call for Contributions

[Manu Bretelle]

OARC 37 will be an *online/hybrid* meeting on *February 17th and 18th 2022**
starting **at 16:00 UTC (10:00 CST)**. *The onsite part of the meeting will
be held in Austin, Texas.

The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are welcome.
For inspiration, we provide a non-exhaustive list of ideas:

- Operations: Any operational gotchas, lessons learned from an outage,
details/reasons for a recent outage (how to improve TTR, tooling).
- Deployment: Managing DNS changes and propagation, release process, change
management.
- Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly
detection.
- Scaling: Managing service capacity, failovers, disaster recovery.


As it is an *online/hybrid *workshop, we'd like to encourage brevity;
presentations should not be longer than 20 minutes (with additional time
for questions).

**Workshop Milestones:**

* 27 December 2021 - Submissions open via Indico
* 10 January 2022 - Deadline for submission (23:59 UTC)
* 11 January 2022 - Initial Contribution list published
* 18 January 2022 - Full agenda published
* 3 February 2022 - Deadline for slideset submission and Rehearsal
* 17 & 18 February 2022 - OARC 37 Workshop

The Registration page and details for presentation submission are published
at:

<https://www.dns-oarc.net/oarc37>

DNS-OARC provides registration fee waivers for the workshop to support
those who are part of underrepresented groups at DNS-OARC. See the
registration page for details.

To allow the Programme Committee to make objective assessments of
submissions, so as to ensure the quality of the workshop, submissions
SHOULD include slides. Draft slides are acceptable on submission.

Additional information for speakers of OARC 37:

* your talk will be broadcast live and recorded for future reference
* your presentation slides will be available for delegates and others to
download and refer to, before, during and after the meeting
* you will be expected to attend a rehearsal on *3rd February 2022**.* It
would be very useful to have your slides (even if draft) ready for this.

If you have questions or concerns you can contact the Programme Committee:

https://www.dns-oarc.net/oarc/programme

via 

*Manu Bretelle, for the DNS-OARC Programme Committee*

OARC depends on sponsorship to fund its workshops and associated social
events.  Please contact  if your organization is
interested in becoming a sponsor.

(Please note that OARC is run on a non-profit basis, and is not in a
position to reimburse expenses or time for speakers at its meetings.)
___
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 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] 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  > <mailto:r...@dnss.ec>> 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.
> &g

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

[Manu Bretelle]

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.

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.

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. 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.


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.

Thanks,
Manu


>
> 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] NXDOMAIN and RFC 8020

[Manu Bretelle]

On Tue, Apr 6, 2021 at 12:51 PM Shumon Huque  wrote:
>
> On Tue, Apr 6, 2021 at 3:03 PM Murray S. Kucherawy  
> wrote:
>>
>> On Tue, Apr 6, 2021 at 11:48 AM Shumon Huque  wrote:
>>>
>>> Without DNSSEC, there is no current way to provide an indication about the 
>>> longest ancestor of the name that did exist. With DNSSEC, the NSEC or NSEC3 
>>> records in the response can do this (as well as providing cryptographic 
>>> proof of this assertion with their signatures).
>>
>>
>> Thanks, this (and the others) is helpful.
>>
>> Focusing on "no current way", could the process described in RFC 8020 
>> theoretically be amended to do so?  It's fine if the answer is "no", but I'd 
>> love to understand why if that's the case.
>
>
> I suspect the most common answer to your question will be "No, just deploy 
> DNSSEC". I'm sure one could devise a new protocol enhancement that an 
> authoritative server could use to convey this information, but I'm not sure 
> it is worth complicating the protocol to do so.
>
> Also, even with 8020, there have been concerns raised that resolvers 
> implementing it, could be vulnerable to spoofing adversaries easily pruning 
> entire subtrees from their caches (rather than having to spoof many 
> individual names). Unbound, for example, implements 8020 only for signed 
> zones.

Murray, an organization we both know very well, do not implement
ENT/RFC8020 for instance... In the case of DNSSEC you get proper
coverage with NSEC even if at best you use White (RFC4470) and Black
(https://tools.ietf.org/html/draft-valsorda-dnsop-black-lies-00) lies.

Manu

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

Re: [DNSOP] Meeting feedbacks/summary on draft-bretelle-dnsop-recursive-iprange-location

[Manu Bretelle]

Thanks both,

So, I seem to gather that the main problem is to put forward Geolocation as
a way to return pseudo-targeted answers to end-users by using the resolver
IP as a proxy for it. This was more meant to be a use-case as to how geo
location has been used, but It is by no means my intent to push this as a
recommended solution. I am happy to drop this or rephrase.

I do believe that Geo can have other useful properties as Brian has
highlighted, even more so in an infrastructure that heavily relies on
anycast. I suppose in most cases one could find other approaches to get
that information whether the traffic coming from a given network is
legitimate, but in many cases, this will involve having access/knowledge to
the full stack (routing tables, peering links, AS paths...) which may not
be readily available to the ones operating DNS. Likely geo is not a perfect
proxy, but it does provide high enough signal that one can leverage.

Manu



On Fri, Nov 20, 2020 at 9:49 AM Brian Dickson 
wrote:

>
> On Thu, Nov 19, 2020 at 9:35 AM Ben Schwartz  40google@dmarc.ietf.org> wrote:
>
>>
>> I do not support the geolocation function.  I think the right solution
>> here is ECS.  Even bad IP-geolocation from ECS will be better than using
>> the recursive resolver's country-code; at least it will be estimating the
>> location of the right entity.
>>
>> If ECS is not widely deployed enough for your purposes, I would focus on
>> ways to increase support for ECS.  For example, we could work on ways
>> to use shorter prefixes for improved privacy where appropriate, or provide
>> guidance on how to use ECS for geo-based responses.
>>
>
> I agree with the sentiment against providing differentiated answers based
> on the geo of the resolver (mostly).
>
> However, geo has other valuable uses.
> Thus, I'd like to retain geo as part of the standard.
> I think recommending against using it as a proxy for ECS should be
> included (with explanation, obviously).
>
> One reason to have explicit geolocation is that the geoip of the
> resolver's IP may not be accurate or timely, and for these use cases,
> explicit geo info is always better.
>
> One use case I raised at the meeting at the mic was grouping providers'
> regional resolvers for various purposes on the authority servers' side.
> Those things would include treating a regional group the same as a single
> resolver, for purposes of white-listing, or rate-limiting, or other
> operational activity.
>
> There are other kinds of things that authority operators would be able to
> do, some of which cannot be done today.
> Those include:
>
>- Alerting on changes in affinity between resolver groups and
>authority instances (which might indicate a routing problem or outage)
>- Visibility on new deployments of resolver groups by a particular
>resolver operator (which might benefit from resource allocation work on the
>authority operator)
>- Ability to detect or prevent spoofing of resolver IP addresses
>- Ability to do cooperative work around ADoT
>- Ability to correlate oddities (e.g. unexpected DNS cookies, set by
>auth location A but seen by auth location B, associated with IP and
>resolver Geo info)
>
> On the other hand, I could see a potential longer-term replacement of ECS
> with ECG (EDNS client geo) once the geo stuff is standardized.
>
> But let's not get distracted by that in the short term, where direct use
> of resolver geo has real value.
>
> Brian
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Meeting feedbacks/summary on draft-bretelle-dnsop-recursive-iprange-location

[Manu Bretelle]

 focus on the details of using
geo location to perform DNS targeted answers as the goal of this document.
It is not, it is just an example use cases that is used in many places.
I should have probably left the geolocation part aside, but givemn that
RFC8805 was providing support to distribute the location at the same time,
I merged the geolocation with it.

Agreeing on using RFC8805 to distribute the data is probably not the most
difficult, but discovery mechanism it going to be more challenging. Should
there be 2 drafts? 1 that focuses on the medium/format and 1 that focuses
on the discovery?

Thanks all,

Manu





[0]
https://datatracker.ietf.org/doc/draft-bretelle-dnsop-recursive-iprange-location/
[1] https://www.rfc-editor.org/rfc/rfc8805.html
[2] https://tools.ietf.org/html/draft-ietf-opsawg-finding-geofeeds-00
[3]
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html
[4] https://ns1.com/resources/understanding-ns1s-geofilters
[5] https://help.dyn.com/traffic-director-predefined-geographic-regions/
[6]
https://learn.akamai.com/en-us/webhelp/global-traffic-management/global-traffic-management-user-guide/GUID-65EB07B3-1BE3-40DB-8682-50E6836A8A78.html
[7] https://kb.isc.org/docs/aa-01149
[8] https://doc.powerdns.com/authoritative/backends/geoip.html
[9]
https://www.knot-dns.cz/docs/2.7/singlehtml/index.html#geoip-geography-based-responses
[10] https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02
[11] https://tools.ietf.org/html/rfc7553
[12] https://tools.ietf.org/html/rfc3123
[13]
https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml#address-family-numbers-2
[14] https://tools.ietf.org/html/rfc5870
[15] https://en.wikipedia.org/wiki/List_of_countries_without_an_airport

On Wed, Nov 4, 2020 at 3:00 PM Manu Bretelle  wrote:

> Hi all,
>
> There is currently no streamlined way for recursive resolver operators to
> distribute the IP ranges/locations that their server farm may use. It is
> currently a mixture of csv files shared over email, or web pages with
> formats that may be unique to each provider and rarely directly parseable
> by automation.
>
> This document is an attempt to provide a consistent mechanism that
> recursive providers can use to distribute their ranges/locations, and auth
> providers can use to apply the policies they may wish to.
>
> Thanks
>
> Manu
>
>
> ---
> A new version of I-D, draft-bretelle-dnsop
> -recursive-iprange-location-01.txt
> has been successfully submitted by Emmanuel Bretelle and posted to the
> IETF repository.
>
> Name:   draft-bretelle-dnsop-recursive-iprange-location
> Revision:   01
> Title:  Recursive Resolvers IP Ranges location distribution and
> discovery
> Document date:  2020-10-29
> Group:  Individual Submission
> Pages:  6
> URL:
> https://www.ietf.org/archive/id/draft-bretelle-dnsop-recursive-iprange-location-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-bretelle-dnsop-recursive-iprange-location/
> Html:
> https://www.ietf.org/archive/id/draft-bretelle-dnsop-recursive-iprange-location-01.html
> Htmlized:
> https://tools.ietf.org/html/draft-bretelle-dnsop-recursive-iprange-location-01
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-bretelle-dnsop-recursive-iprange-location-01
>
> Abstract:
>This document specifies a way for recursive resolvers operators to
>signal the IP ranges and locations used by their server pools.
>
> 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/chantra/draft-dns-recursive-iprange-location.
>
>
>
>
>
>
> 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] draft-bretelle-dnsop-recursive-iprange-location

[Manu Bretelle]

Hi all,

There is currently no streamlined way for recursive resolver operators to
distribute the IP ranges/locations that their server farm may use. It is
currently a mixture of csv files shared over email, or web pages with
formats that may be unique to each provider and rarely directly parseable
by automation.

This document is an attempt to provide a consistent mechanism that
recursive providers can use to distribute their ranges/locations, and auth
providers can use to apply the policies they may wish to.

Thanks

Manu


---
A new version of I-D, draft-bretelle-dnsop-recursive-iprange-location-01.txt
has been successfully submitted by Emmanuel Bretelle and posted to the
IETF repository.

Name:   draft-bretelle-dnsop-recursive-iprange-location
Revision:   01
Title:  Recursive Resolvers IP Ranges location distribution and
discovery
Document date:  2020-10-29
Group:  Individual Submission
Pages:  6
URL:
https://www.ietf.org/archive/id/draft-bretelle-dnsop-recursive-iprange-location-01.txt
Status:
https://datatracker.ietf.org/doc/draft-bretelle-dnsop-recursive-iprange-location/
Html:
https://www.ietf.org/archive/id/draft-bretelle-dnsop-recursive-iprange-location-01.html
Htmlized:
https://tools.ietf.org/html/draft-bretelle-dnsop-recursive-iprange-location-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-bretelle-dnsop-recursive-iprange-location-01

Abstract:
   This document specifies a way for recursive resolvers operators to
   signal the IP ranges and locations used by their server pools.

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/chantra/draft-dns-recursive-iprange-location.





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