On 08/07/2025 17:42, John Levine wrote:
It appears that Yorgos Thessalonikefs <yor...@nlnetlabs.nl> said:
Various ways that could give resolution inconsistencies between
implementations (I am not considering the actual attack scenario because
noone cares about that resolution).
Different resolvers allow different lengths of CNAME chains before they give up.
I think that's much more likely to make a practical difference, but we've been
living with it for decades and dnsop has never provided definitive advice on
how to deal with it.
Why is this any more urgent?
For me it is the same issue. Both need to be solved coherently.
There is actually
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-dns-upper-limit-values/
that tries to address such inconsistencies but it is off topic for this
thread.
For CNAMEs specifically there is a rollercoaster of changed default
values between implementations, configuration options so that users can
shoot their own feet and still we get user issues because of CNAME abuse
in CDNs.
The standard allows anything so picking a value as a zone
author/operator/maintainer needs prior knowledge of current default
options in available resolves and possible well known installations with
their own set values.
Btw, an honest question to the working group, is it more desirable for
such issues, as the key tag collision we are discussing here and the
CNAME chain length for example, to be addressed with a flag day or a
standard document?
Best regards,
-- Yorgos
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
