-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Is this example for considering that a 128.0.0.0/4/8 answer is
> different from a 128.0.0.0/4/4 answer when both are available
> answers to be returned by an auth for a 128.0.0.0/4/0 query?
Both 128.0.0.0/4/8 and 128.0.0.0/4/4 could satisfy a 128.0.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I don't follow. Are you saying you are saving the SOURCE
> PREFIX-LENGTH from the original query (responsible for the cache
> entry) alongside the cache entry?
Yes.
> If so, I don't follow why this is required. Can you explain?
Certainly!
Suppose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Mukund,
> The draft doesn't state that the answer is for the SOURCE
> PREFIX-LENGTH when SCOPE > SOURCE. At all other times, the answer
> is meant to be cached at the SCOPE PREFIX-LENGTH.
I indeed use SCOPE to determine where the answer would fit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a hard time understanding your need for DIRECTION and DEPTH,
and would argue you'd have enough information as is.
>
> IPv4 root [A2(/0)**] / \ 0b0.. /\ 0b1.. / \ A2(/1)X /
> \ / \ 0b10.. / \ 0b11.. / \ A2(/2) X
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Please correct me if I'm wrong. I think there is a problem in this
draft.
Although the draft explicitly addresses Birthday Attacks it is still
vulnerable. Section 10.2 (Birthday Attacks) states:
> To counter this, every edns-client-subnet option in a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
On 18-02-15 18:19, Marcus Grando wrote:
>>> If the SCOPE NETMASK in the reply is longer than the SOURCE
>>> NETMASK,
> it means that the reply might be suboptimal. A Recursive Resolver
> MUST return this entry from cache only to queries that do no
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/31/2014 08:31 PM, 神明達哉 wrote:
> - Section 6.3
>
> If the address of the client is within any of the networks in the
> cache, then the cached response MUST be returned as usual. If the
> address of the client matches multiple networks in the c
On 09/06/2012 01:44 PM, Tony Finch wrote:
>> - Bullet point 1 says that the ZSK Double Signature rollover is also
>> known as Double-DNSKEY. I have not heard of this term before reading
>> this document. Is it really known as?
> Double-KSK would be a better term, since Double-DNSKEY sounds like th
On 08/20/2012 01:50 PM, John Dickinson wrote:
> We could rearrange the table to tidy up the description of the
> Double-Signature method but keep the existing names. Would that
> help?
Yes, making a clearer distinction between ZSK Double-Signature and KSK
Double-Signature would help a bit.
//yu
| -| Double-KSK | Publish DNSKEY and DS in|
| | | parallel. |
+--+--+-+
Regards,
Yuri Schaeffer
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
that in order to find a
satisfying amount of iterations it is sufficient to look at the
performance impact of the authoritative name server.
Regards,
Yuri Schaeffer
- --
Yuri Schaeffer
NLnet Labs
http://www.nlnetlabs.nl
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment
11 matches
Mail list logo
