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
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
.
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
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
://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
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
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
://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
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
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
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 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, 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
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
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
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
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
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
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
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
>
>
> 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 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
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
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
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.
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
*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
27 matches
Mail list logo
