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 line
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" in its title.
> >
>
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 t
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 =
>
> > differe
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 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 it specifically says
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 th
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 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 authoritative name servers properly ha
> > 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 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 error"
> 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 Response.
>
> That's c
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 th
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 cases
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. (there
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
; <<>> DiG 9.9.5-9+deb8u3-
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:
>
>> Regarding Section 5 (possible side e
[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 sooner than this propo
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, wrote:
> Please check this algorithm.
Several times, the phrase "query as usual" is used. However, something
might need to be said
Thanks to Jinmei, Shumon and Mark.
> From: 神明達哉
> 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 unnecessary
On Tue, Jul 14, 2015 at 1:00 PM, 神明達哉 wrote:
> At Mon, 13 Jul 2015 22:01:29 -0400,
> Shumon Huque 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 sooner than this propo
At Mon, 13 Jul 2015 22:01:29 -0400,
Shumon Huque 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 to suppr
In message
, Shumon Huque writes:
>
> On Fri, Jul 10, 2015 at 2:53 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 e...@wide.ad.jp> wrote:
>
> > On Tue, Jul 7, 2015 at 2:20 AM, wrote:
> > [...]
> > In Introduction it states:
> >
> >While negative (non-existence) information of DNS caching mechan
On Fri, Jul 10, 2015 at 2:53 PM, 神明達哉 wrote:
> On Tue, Jul 7, 2015 at 2:20 AM, wrote:
> [...]
> In Introduction it states:
>
>While negative (non-existence) information of DNS caching mechanism
>has been known as DNS negative cache [RFC2308], it requires exact
>matching in most case
On Tue, Jul 7, 2015 at 2:20 AM, wrote:
> 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 Cachi
> From: Bob Harold
> On Tue, Jul 7, 2015 at 5:20 AM, 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
>>
>> I am concerned that t
On Tue, Jul 7, 2015 at 5:20 AM, 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
>
> I am concerned that the "AN" flag allows for easy zone wal
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 Append
29 matches
Mail list logo
