On Feb 20, 2024, at 5:42 AM, Edward Lewis wrote:
>
> On 2/16/24, 15:05, "DNSOP on behalf of Mark Andrews" on behalf of ma...@isc.org> wrote:
>
> Pardon ... perhaps this issue has died down, but I've been off a few days,
> and I just saw this...
>
>> Generating a new key is not hard to do.
>
> On Feb 15, 2024, at 9:53 AM, Paul Hoffman wrote:
>
> On Feb 15, 2024, at 09:48, Wellington, Brian
> <mailto:bwelling=40akamai@dmarc.ietf.org>> wrote:
>>
>>
>>
>>> On Feb 15, 2024, at 6:02 AM, Paul Wouters wrote:
>>>
>>
> On Feb 15, 2024, at 6:02 AM, Paul Wouters wrote:
>
> On Feb 15, 2024, at 04:37, Petr Špaček wrote:
>>
>> If you think colliding keys should be allowed, please propose your own
>> limits for sensible behavior.
>
> I do think they need to be allowed because they have always been allowed so
> On Feb 8, 2024, at 6:41 AM, Edward Lewis wrote:
>
> ...
>
> When DNSSEC was designed, the possibility of tags colliding was known. The
> validation process was defined to expect that a tag might lead to a
> non-singleton set of keys. When it came to key management, and the practice
> of
To ensure compatibility with complex SvcParam specifications, recursive
resolvers MAY validate the values of recognized SvcParamKeys, but MUST NOT
reject the record on this basis unless a value is obviously invalid.
On Wed, Apr 21, 2021 at 3:18 PM Wellington, Brian
mailto:40akamai@dmarc.ietf.o
On Apr 21, 2021, at 11:58 AM, Ben Schwartz
mailto:bemasc=40google@dmarc.ietf.org>>
wrote:
On Wed, Apr 21, 2021 at 1:24 PM Wellington, Brian
mailto:40akamai@dmarc.ietf.org>>
wrote:
Yes, I think that sentence should be changed. I’d suggest removing the
"malform
oogle@dmarc.ietf.org>>
wrote:
On Wed, Apr 21, 2021 at 12:44 PM Wellington, Brian
mailto:40akamai@dmarc.ietf.org>>
wrote:
I’m not a fan of the new text in section 4.3:
Recursive resolvers MUST be able to convey SVCB records with unrecognized
SvcParamKeys or malformed SvcPa
I’m not a fan of the new text in section 4.3:
Recursive resolvers MUST be able to convey SVCB records with unrecognized
SvcParamKeys or malformed SvcParamValues.
It is perfectly reasonable for a recursive resolver to reject any malformed DNS
record. There’s a significant difference between “ma
RFC 1035 says “prior occurance”, which would mean no.
4.1.4. Message compression
In order to reduce the size of messages, the domain system utilizes a
compression scheme which eliminates the repetition of domain names in a
message. In this scheme, an entire domain name or a list of labels at
the
Hi Duane,
I’m not sure if I completely agree with this analysis. The issue isn’t about
validation; it’s about parsing the presentation format. The RFC says:
When SHA384 is used, the size of the
Digest field is 48 octets. The result of the SHA384 digest algorithm
MUST NOT be truncate
; In wire format, the keys are represented by their numeric values in network
>> byte order,
>> concatenated in ascending order.
>>
>> This SvcParamKey is always automatically mandatory, and MUST NOT appear in
>> its own
>> value list. Other autom
ears. If I’m having trouble understanding this, perhaps the spec should be
>> a bit clearer.
>>
>> Brian
>>
>>> On Jul 22, 2020, at 5:56 PM, Tommy Pauly
>>> wrote:
>>>
>>>
>>>
>>>> On Jul 22, 2020, at 5:46 PM,
speaker, and have been working with DNS for over 20 years.
If I’m having trouble understanding this, perhaps the spec should be a bit
clearer.
Brian
On Jul 22, 2020, at 5:56 PM, Tommy Pauly
mailto:tpauly=40apple@dmarc.ietf.org>>
wrote:
On Jul 22, 2020, at 5:46 PM, Wellington,
I attempted to start implementing support for SVCB and HTTPS, and discovered
that the data being served by Cloudflare does not conform to the current spec.
Assuming my decoder is correct, the response below decodes to:
1 . alpn=h3-29,h3-28,h3-27,h2 echconfig=aBIaLmgSGy4=
ipv6hint=2606:4700::681
SIG(0) was implemented in BIND 9 back when BIND 9 was basically the only modern
implementation, and no one used it then. The fact that no servers have
implemented it since then means that there really isn’t any demand.
Brian
> On Jun 19, 2018, at 2:20 PM, Mark Andrews wrote:
>
> SIG(0) is
15 matches
Mail list logo
