On Wed, Nov 21, 2018 at 1:50 PM Martin Thomson
wrote:
> In attempting to fix a bug related to this, a question came up about
> what the semantics of an empty value is here. Some implementations
> seem to infer that empty means {*,SHA1}, which effectively assumes
> that an empty value is
On Wed, Nov 21, 2018 at 3:50 PM Martin Thomson
wrote:
> In attempting to fix a bug related to this, a question came up about
> what the semantics of an empty value is here. Some implementations
> seem to infer that empty means {*,SHA1}, which effectively assumes
> that an empty value is
In attempting to fix a bug related to this, a question came up about
what the semantics of an empty value is here. Some implementations
seem to infer that empty means {*,SHA1}, which effectively assumes
that an empty value is equivalent to an absent signature_algorithms
extension (Section
> On Nov 21, 2018, at 4:50 PM, Martin Thomson wrote:
>
> In attempting to fix a bug related to this, a question came up about
> what the semantics of an empty value is here. Some implementations
> seem to infer that empty means {*,SHA1}, which effectively assumes
> that an empty value is
* Paul Wouters:
> On Wed, 21 Nov 2018, Stephen Farrell wrote:
>
>>> We currently permit >1 RR, but
>>> actually
>>> I suspect that it would be better to try to restrict this.
>>
>> Not sure we can and I suspect that'd raise DNS-folks' hackles,
>> but maybe I'm wrong.
>
> I think the SOA record is
On Tue, Nov 20, 2018 at 11:28 PM Paul Wouters wrote:
> Although, if I am correct, the epectation is that all of this data
> will be used without mandating DNSSEC validation, so all these
> security parameters could be modified by any DNS party in transit
> to try and break the protocol or
On Thu, Nov 22, 2018 at 9:08 AM David Benjamin wrote:
> Maybe we should errata this by fixing that <2^16-1> to <2..2^16-1>?
https://www.rfc-editor.org/errata/eid2864 was filed a while ago.
Apparently also erratum 1585 found an error.
We really need a view of these documents that includes
