I am in favor of adopting this work.
Manu
On Tue, Apr 15, 2025 at 1:39 AM Benno Overeinder wrote:
> All,
>
> At IETF 122, there appeared to be some agreement to adopt this work
> within DNSOP.
>
> Below are the relevant meeting minutes and a link to the presentation
> from the session:
>
> A To
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, 20
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
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 kno
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 peopl
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 intereste
an 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
://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
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...@dn
c.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 i
://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
vided 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
even
.
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
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-profi
t 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
*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 meet
e 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
ished 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.
ontact 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
t
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 it
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
>
>
> 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 tech
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 hav
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 d
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
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 pu
ss-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 resolv
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
28 matches
Mail list logo
