sanity check, someone?
i believe that in dnssec, an empty non-terminal has a proof that the
name exists, and a proof that there are no RR's. thus, vastly different
from the signaling for NXDOMAIN.
Yes, it does. With NSEC3 it is an explicit proof. With NSEC you have to
read between the
Speaking only for myself, though I happen to be one of the authors.
On 26 Oct 2015, at 9:08, Ray Bellis wrote:
RFC 4035 §3.1.3.2 appears to say differently :(
The subject of that section is "Including NSEC RRs: Name Error
Response", and it says:
"Note that this form of response includes
On 26/10/2015 09:52, I wrote:
> That's clear - what isn't perhaps, is what the RCODE should be, given
> that this text is in a section with "Name Error" in its title.
For what it's worth, I expect the answer to be NOERROR, but I think the
text that lumps empty-non-terminals in with "name
On 26/10/2015 09:50, Roy Arends wrote:
> Speaking only for myself, though I happen to be one of the authors.
>
> ...
>
> An Empty Non Terminal NoData response requires the same NSEC records as
> an Name Error Response.
That's clear - what isn't perhaps, is what the RCODE should be, given
that
> On 26 Oct 2015, at 09:52, Ray Bellis wrote:
>
>
>
> On 26/10/2015 09:50, Roy Arends wrote:
>> Speaking only for myself, though I happen to be one of the authors.
>>
>> ...
>>
>> An Empty Non Terminal NoData response requires the same NSEC records as
>> an Name Error
On 26/10/2015 06:39, Paul Vixie wrote:
> sanity check, someone?
>
> i believe that in dnssec, an empty non-terminal has a proof that the
> name exists, and a proof that there are no RR's. thus, vastly
> different from the signaling for NXDOMAIN.
RFC 4035 §3.1.3.2 appears to say differently :(
sanity check, someone?
i believe that in dnssec, an empty non-terminal has a proof that the name
exists, and a proof that there are no RR's. thus, vastly different from the
signaling for NXDOMAIN.
this ought to end, for all time, the debate about whether empty nonterminals
exist or not.
In message <562ded9e.40...@bellis.me.uk>, Ray Bellis writes:
> On 26/10/2015 06:39, Paul Vixie wrote:
> > sanity check, someone?
> > =
>
> > i believe that in dnssec, an empty non-terminal has a proof that the =
>
> > name exists, and a proof that there are no RR's. thus, vastly =
>
> >
On Monday, October 26, 2015 10:15:37 AM Ray Bellis wrote:
> On 26/10/2015 09:52, I wrote:
> > That's clear - what isn't perhaps, is what the RCODE should be, given
> > that this text is in a section with "Name Error" in its title.
>
> For what it's worth, I expect the answer to be NOERROR, but I
On Mon, Oct 26, 2015 at 10:03 PM, Paul Vixie wrote:
> On Monday, October 26, 2015 10:15:37 AM Ray Bellis wrote:
> > On 26/10/2015 09:52, I wrote:
> > > That's clear - what isn't perhaps, is what the RCODE should be, given
> > > that this text is in a section with "Name Error"
As a Chair, I'm actually very happy were' having deeper discussions
around this draft. I think there is some good work inside here, and it
appears that the WG feels the same.
tim
On 10/26/15 11:59 AM, Ray Bellis wrote:
On 26/10/2015 15:32, Evan Hunt wrote:
But RFC 5155 is clear on
> > i believe that in dnssec, an empty non-terminal has a proof that the
> > name exists, and a proof that there are no RR's. thus, vastly
> > different from the signaling for NXDOMAIN.
>
> RFC 4035 §3.1.3.2 appears to say differently :(
But RFC 5155 is clear on the subject; empty non-terminal
On Mon, Oct 26, 2015 at 11:59 AM, Ray Bellis wrote:
>
>
> On 26/10/2015 15:32, Evan Hunt wrote:
>
> > But RFC 5155 is clear on the subject; empty non-terminal nodes are
> > mentioned under "no data" rather than "name error".
>
> Ah, thanks, that's useful to know, and further
On Sun, Oct 25, 2015 at 6:49 AM, Stephane Bortzmeyer
wrote:
> On Sat, Oct 24, 2015 at 10:54:15PM +,
> P Vixie wrote
> a message of 73 lines which said:
>
> > To me this is a feature, possibly the most important feature.
>
> Specially now that Akamai's
On 26/10/2015 15:32, Evan Hunt wrote:
> But RFC 5155 is clear on the subject; empty non-terminal nodes are
> mentioned under "no data" rather than "name error".
Ah, thanks, that's useful to know, and further it specifically says that
the NSEC3 ETN response is different to an NSEC ETN response.
On Sun, Oct 25, 2015 at 11:39:25PM -0700, Paul Vixie wrote:
> sanity check, someone?
Yes, you're quite sane. :-)
> I believe that in dnssec, an empty non-terminal has a proof that the name
> exists, and a proof that there are no RR's. thus, vastly different from the
> signaling for NXDOMAIN.
On Sat, Oct 24, 2015 at 10:54:15PM +,
P Vixie wrote
a message of 73 lines which said:
> To me this is a feature, possibly the most important feature.
Specially now that Akamai's authoritative name servers properly handle
ENTs:
% dig A e8921.dscx.akamaiedge.net
; <<>>
[Re-reading all emails...]
On Fri, Jul 10, 2015 at 11:53:30AM -0700,
神明達哉 wrote
a message of 62 lines which said:
> Regarding Section 5 (possible side effect on root servers), I wonder
> about the implication of qname-minimization (which I expect will be
> deployed much
To me this is a feature, possibly the most important feature.
On October 25, 2015 6:16:54 AM GMT+11:00, Stephane Bortzmeyer
wrote:
>[Re-reading all emails...]
>
>On Fri, Jul 10, 2015 at 11:53:30AM -0700,
> 神明達哉 wrote
> a message of 62 lines which said:
>
Thanks to Jinmei, Shumon and Mark.
From: 神明達哉 jin...@wide.ad.jp
While I see what it tries to say and don't disagree with it, I think
this is not very accurate. In fact, NXDOMAIN for a.example.com says
there is no such name *or any subdomain of it*. So it would still be
usable to suppress
Hi,
Some thoughts below, strictly on the NSEC/NSEC3 algorithm. They're quite
rough, but hopefully they're useful.
Cheers,
Casey
On Tue, Jul 7, 2015 at 5:20 AM, fujiw...@jprs.co.jp wrote:
Please check this algorithm.
Several times, the phrase query as usual is used. However, something
On Tue, Jul 14, 2015 at 1:00 PM, 神明達哉 jin...@wide.ad.jp wrote:
At Mon, 13 Jul 2015 22:01:29 -0400,
Shumon Huque shu...@gmail.com wrote:
Regarding Section 5 (possible side effect on root servers), I wonder
about the implication of qname-minimization (which I expect will be
deployed much
At Mon, 13 Jul 2015 22:01:29 -0400,
Shumon Huque shu...@gmail.com wrote:
While I see what it tries to say and don't disagree with it, I think
this is not very accurate. In fact, NXDOMAIN for a.example.com says
there is no such name *or any subdomain of it*. So it would still be
usable
In message CAHPuVdU-1e_7KPH9JdSvbPn-tYptaXbHrQvQz=uev+qjdse...@mail.gmail.com
, Shumon Huque writes:
On Fri, Jul 10, 2015 at 2:53 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 jinm=
e...@wide.ad.jp wrote:
On Tue, Jul 7, 2015 at 2:20 AM, fujiw...@jprs.co.jp wrote:
[...]
In Introduction it
On Fri, Jul 10, 2015 at 2:53 PM, 神明達哉 jin...@wide.ad.jp wrote:
On Tue, Jul 7, 2015 at 2:20 AM, fujiw...@jprs.co.jp wrote:
[...]
In Introduction it states:
While negative (non-existence) information of DNS caching mechanism
has been known as DNS negative cache [RFC2308], it requires
From: Bob Harold rharo...@umich.edu
On Tue, Jul 7, 2015 at 5:20 AM, fujiw...@jprs.co.jp wrote:
Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01.
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
...
--
Kazunori Fujiwara, JPRS
Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01.
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
* Added reference to DLV {{RFC5074}} and imported some sentences.
* Added Aggressive Negative Caching Flag idea.
* Added detailed algorithms in
27 matches
Mail list logo