Petr Špaček <petr.spa...@nic.cz> wrote:
>
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?
The feature I would like is CNAME and other data (typically CNAME + MX +
TXT), because I have a lot of deeply hierarchial subdomains in my main
zone. CNAME at apex does not need to be (and I think should not be treated
as) a special case.
As I understand it, in the RFC 883 era, CNAME was allowed to coexist with
other records, but that led to consistency problems. eg, if you have a
CNAME cached for a particular name, and you get a query for MX at the same
name, do you go and ask the CNAME's owner or its target for the MX? And do
you get a different answer to the MX query when you don't have a CNAME
cached?
My guess is that it was hard to fix this at the time because the semantics
of negative cache entries was not well developed (e.g. RFC 1034 section
4.3.4 says it was still a new and experimental feature). For
CNAME-with-siblings to work, a resolver needs to remember whether it
already asked for the other data, for each RR type. 1980s caches couldn't
do this, so CNAMEs were made exclusive instead.
I think the resolver's algorithm for handling CNAMEs can be updated to
allow CNAME-with-siblings and preserve compatibility. There will be some
latency cost for later queries that can no longer immediately follow the
CNAME shortcut. NSEC/NSEC3 records could be used to eliminate this cost.
I'm much less sure about whether it's possible to publish
CNAME-with-siblings in a reliably compatible way. I would feel a lot more
comfortable with an ANAME implementation that copies the sibling records
from the target to the owner when the zone is published or signed.
Tony.
--
f.anthony.n.finch <d...@dotat.at> http://dotat.at/
Trafalgar: Cyclonic, mainly northeasterly in northwest, 5 to 7. Slight or
moderate until later in southeast, otherwise moderate or rough. Thundery
showers, fog patches later. Moderate or good, occasionally very poor later.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
