Dear all,
Today, I released a new version of the draft:
https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-02.
I replaced the term "record" with "resource record", updated the
reference to the EDNS RFC, and added an Acknowledgements section.
@Peter Thomassen: Is it possible
Reviewer: Mališa Vučinić
Review result: Has Nits
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. Document
editors and WG chairs should treat these comments just like any other last call
comments.
This doc
> The IETF does not create standards for APIs. So a validating stub resolver is
>
> not really something that can be defined, because it is not a protocol.
I beg to differ here. It may not be strictly part of the DNS protocol, but then
this logic needs to be a part of every single protocol dep
Hi,
After the presentation by regext this week it turned out that this work
can be also of interest of dnsop WG.
Few slides from regext show especially the current implementation status
and adoption
https://datatracker.ietf.org/meeting/120/materials/slides-120-regext-sessa-domain-connect-u
Scott,
Yes, new qualified names (identifiers) for new things will disambiguate from
existing names. The important thing is to avoid a truly "split horizon" DNS
situation where the same qualified name means different things in different
contexts (the lack of specific records visible from a contex
> On 25 Jul 2024, at 05:49, Martin Schanzenbach wrote:
>
>
>
> On Thu, 2024-07-25 at 14:39 +0200, Philip Homburg wrote:
>>> As hinted to in the CVE description, Thomas asked here where this
>>> behaviour is defined exactly and did not receive a response that
>>> fits this issue:
>>> https://m
This is not needed. Additionally when answers are returned the zone is not
known.
This is true of both stub resolvers and non validating recursive resolvers.
As for your MX example one could use existing DNS compression mechanisms on the
wire and when storing the record if desired by using an of
It appears that Paul Hoffman said:
>The problems are listed as:
>
>Colliding key tags impose additional work on a validating resolver, which then
>has to check
>signatures for each of the candidate set of keys identified by the Key Tag.
>Furthermore, they
>open up resolvers to computational den
This expectation setting. Adjusting key generation won’t happen
unless there is a written requirement for it to happen. If we where
to say duplicate keys tags are no longer supported as of date X
there is no way the operators of all the existing signed zones with
duplicate tags would know to perfo
On Wed, Jul 24, 2024 at 10:18 AM Shumon Huque wrote:
>
> On your last point, yes, I think we can say that if a verifier sees
> multiple
> validation records, they can abort.
>
>
I'd think it would be better to allow looking at the full RRset and
succeeding if any of the records match?
This seems
On Fri, 26 Jul 2024, Erik Nygren wrote:
On your last point, yes, I think we can say that if a verifier sees
multiple validation records, they can abort.
I'd think it would be better to allow looking at the full RRset and
succeeding if any of the records match?
No. These records are suppose
Even if we where to go with one failure is allowed we still need to
write down the new rules and there will be complaints that we are
retrospectively changing the rules. This is grand fathering in the
old rules for the old algorithms.
Write a BCP, not a standard disallowing key id clashes.
Ri
The following errata report has been submitted for RFC7901,
"CHAIN Query Requests in DNS".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid8053
--
Type: Technical
Reported by: Mark Andrews
Se
> On 26 Jul 2024, at 04:41, Bellebaum, Thomas
> wrote:
>
>> The IETF does not create standards for APIs. So a validating stub resolver
>> is
>> not really something that can be defined, because it is not a protocol.
>
> I beg to differ here. It may not be strictly part of the DNS protocol,
14 matches
Mail list logo
