A new Request for Comments is now available in online RFC libraries.
BCP 207
RFC 8027
Title: DNSSEC Roadblock Avoidance
Author: W. Hardaker,
O. Gudmundsson,
S. Krishnaswamy
Status: Best Current
Paul Hoffman wrote:
> On 1 Nov 2016, at 10:54, Philip Homburg wrote:
>
> > I find it hard to believe that after compression, the BSON encoded
> > version of the DNS data would be a lot smaller than just the
> > raw DNS data.
>
> Please note the use case in the draft: they don't want to burden the
In message
, Matthew
Pounsett write
s:
> I think this draft is useful and necessary, and that the registration of
> ipv4only.arpa within the SUDN registry is justified by the applicability
> statement of RFC 6761. Having NAT64-unaware recursive servers answer
> authoritatively as they would for
On 11/28/16, 10:43, "DNSOP on behalf of Olafur Gudmundsson"
wrote:
b) pick one at “random"
Please don't use the word random, not even in quotes, in this context. I
suspect that somewhere along the line that a code writer will interpret that to
mean a random number generator is needed.
Other
I think this draft is useful and necessary, and that the registration of
ipv4only.arpa within the SUDN registry is justified by the applicability
statement of RFC 6761. Having NAT64-unaware recursive servers answer
authoritatively as they would for other reserved names (e.g. RFC 1918
address rever
On 28 Nov 2016, at 7:50, Tony Finch wrote:
> Olafur Gudmundsson wrote:
>
>> There have been some discussion on this topic, It is fair to say that
>> there are 3 camps
>>
>> a) answer with the smallest RRSET
>> b) pick one at “random"
>> c) select bases on what is most useful (i.e. deterministic s
Olafur Gudmundsson wrote:
> There have been some discussion on this topic, It is fair to say that
> there are 3 camps
>
> a) answer with the smallest RRSET
> b) pick one at “random"
> c) select bases on what is most useful (i.e. deterministic selection)
>
> I would be happiest to go with b) and
> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking wrote:
>
> Hi,
>
> I have read the draft and have two comments. Both of these have been called
> out before, but I don't see them addressed in this version (-03):
>
> 1. In case of a DNS responder selecting one or a subset of the RRsets at the
Perhaps the bloom-filter idea is something that should be explored
after all (although I admit I don't see the relation to the unsigned
NSEC3 approach)?
I agree they might be interesting, but I'd like to keep them far away from
pseudo-DNSSEC.
Regards,
John Levine, jo...@taugh.com, Taughannock
John,
At 2016-11-27 15:18:18 -
"John Levine" wrote:
> >What are the consequences of the authoritiative server returning
> >synthesized unsigned NSEC3 RRs upon being signalled by the resolver
> >using an EDNS option?
>
> A message to the world that there is no need to sign your zones,
> be
Are we still creating standards based on "BIND does this"? :p
On 28-11-16 13:57, Tony Finch wrote:
Matthijs Mekking wrote:
1. In case of a DNS responder selecting one or a subset of the RRsets at the
QNAME, The draft does not give clear guidance on which RRset(s) to pick.
The code in BIND j
Matthijs Mekking wrote:
>
> 1. In case of a DNS responder selecting one or a subset of the RRsets at the
> QNAME, The draft does not give clear guidance on which RRset(s) to pick.
The code in BIND just picks an arbitrary RRset, without making any effort
to be clever.
It makes an ANY query to the
Hi,
I have read the draft and have two comments. Both of these have been
called out before, but I don't see them addressed in this version (-03):
1. In case of a DNS responder selecting one or a subset of the RRsets at
the QNAME, The draft does not give clear guidance on which RRset(s) to
pi
I don't feel very strongly about renaming the draft. I just find a little bit
confusing and I imagine I might not be the only one who might feel that way.
One way or another I have already reviewed -03 versions of the draft and I think
it is ready for publication.
Cheers,
--
Ondřej Surý -- Tech
14 matches
Mail list logo
