On Mon, 2021-05-10 at 22:09 +0100, Tony Finch wrote:
> Peter van Dijk wrote:
> > Also in section 3.2, I do not think responding with the option should
> > be limited to NOERROR. Specifically, I'd very much also want it to work
> > for NXDOMAIN,
>
> Isn't the SOA record usually present in a negati
Peter van Dijk wrote:
>
> Also in section 3.2, I do not think responding with the option should
> be limited to NOERROR. Specifically, I'd very much also want it to work
> for NXDOMAIN,
Isn't the SOA record usually present in a negative response?
> and I can imagine some cases of it being useful
On Mon, 2021-05-10 at 12:37 -0400, Hugo Salgado wrote:
> Hello everyone. Thanks for the comments, I just uploaded an unchanged
> version (just to revive it) at:
> https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/
Thanks Hugo, that is useful.
In section 3.2, 'the resource record of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I agree with what Hugo said
I would also like to point out that this draft spirit is aiming to be a
debugging tool to be used by humans and not in between servers. If we start
introducing all these new use cases in-between servers (like authoritativ
Hi Vladimir,
On 10 May 2021, at 04:32, Vladimír Čunát wrote:
> On 10. 05. 21 10:19, Petr Špaček wrote:
>> I think the proper solution should be a real multi-query option, which
>> incidentally provides a superset of RRSERIAL capabilities.
>
> If multi-queries require the records being in sync
Hello everyone. Thanks for the comments, I just uploaded an unchanged
version (just to revive it) at:
https://datatracker.ietf.org/doc/draft-salgado-dnsop-RRSERIAL/
I agree RRSERIAL doesn't have much relevance in zones that don't give
serial versioning a meaning to its content. We can add a para
On 10. 05. 21 10:19, Petr Špaček wrote:
I think the proper solution should be a real multi-query option, which
incidentally provides a superset of RRSERIAL capabilities.
If multi-queries require the records being in sync (if from the same
zone), I really dislike the implications of them being
On 27. 01. 20 16:08, Hugo Salgado wrote:
Dear DNSOPers, as an operator I tend to have this need to couple
an answer for a query to an auth server, with the actual "SOA zone
version" used. So I think it'll be valuable to have an EDNS option
for it.
Here I'm proposing it with this new draft. The '
On Mon, 27 Jan 2020 at 10:09, Hugo Salgado wrote:
>
> Dear DNSOPers, as an operator I tend to have this need to couple
> an answer for a query to an auth server, with the actual "SOA zone
> version" used. So I think it'll be valuable to have an EDNS option
> for it.
I also missed this the first t
Seems like a good idea to me. I think the WG should adopt it.
Thanks,
Donald
===
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
On Mon, Jan 27, 2020 at 10:09 AM Hugo Salgado wrote:
>
> Dear DNSOPers, as
On Fri, May 7, 2021 at 10:03 AM Joe Abley wrote:
> Hi Hugo,
>
> On 7 May 2021, at 12:47, Hugo Salgado wrote:
>
> > I'll upload a new version to revive it, and ask for a slot
> > in IETF111 for further discussion!
>
> Just to add my voice to the chorus, I missed this the first time around so
> th
On 7 May 2021, at 13:39, John Levine wrote:
> It appears that Hugo Salgado said:
>> -=-=-=-=-=-
>>
>> I'll upload a new version to revive it, and ask for a slot
>> in IETF111 for further discussion!
>
> It looks like it's worth considering, but I also wonder how
> relevant it is for DNS serve
On Fri, May 07, 2021 at 01:39:56PM -0400, John Levine wrote:
> It appears that Hugo Salgado said:
> >-=-=-=-=-=-
> >
> >I'll upload a new version to revive it, and ask for a slot
> >in IETF111 for further discussion!
>
> It looks like it's worth considering, but I also wonder how
> relevant it i
It appears that Hugo Salgado said:
>-=-=-=-=-=-
>
>I'll upload a new version to revive it, and ask for a slot
>in IETF111 for further discussion!
It looks like it's worth considering, but I also wonder how
relevant it is for DNS servers that don't use AXFR/IXFR and SOA
serial numbers to keep ver
Hi Hugo,
On 7 May 2021, at 12:47, Hugo Salgado wrote:
> I'll upload a new version to revive it, and ask for a slot
> in IETF111 for further discussion!
Just to add my voice to the chorus, I missed this the first time around so
thanks, Mauricio, for mentioning it.
I haven't read the draft in d
I'll upload a new version to revive it, and ask for a slot
in IETF111 for further discussion!
Thanks,
Hugo
On 22:02 06/05, Mauricio Vergara Ereche wrote:
> Hi Hugo,
>
> I just want to bring back to life this topic as it solves an issue that
> several operators (like me) seem to be in need to so
Hi Hugo,
I just want to bring back to life this topic as it solves an issue that
several operators (like me) seem to be in need to solve while debugging
issues.
Mauricio
On Mon, Jan 27, 2020 at 7:09 AM Hugo Salgado wrote:
> Dear DNSOPers, as an operator I tend to have this need to couple
> an
Hi Duane.
On 20:49 27/01, Wessels, Duane wrote:
> Hi Hugo,
>
> I like this proposal and think that DNSOP should adopt it. I agree that it
> will prove valuable in debugging.
>
Great.
> A couple of comments and suggestions:
>
> Sections 2 and 3 could be clarified regarding the value for OPTI
Hi Hugo,
I like this proposal and think that DNSOP should adopt it. I agree that it
will prove valuable in debugging.
A couple of comments and suggestions:
Sections 2 and 3 could be clarified regarding the value for OPTION-LENGTH. I
gather the intention is that OPTION-LENGTH is zero for quer
Dear DNSOPers, as an operator I tend to have this need to couple
an answer for a query to an auth server, with the actual "SOA zone
version" used. So I think it'll be valuable to have an EDNS option
for it.
Here I'm proposing it with this new draft. The 'camel index' for
its implementation/hack/pr
20 matches
Mail list logo
