On Jun 19, 2018, at 10:20, Tony Finch <d...@dotat.at> wrote: > 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.
My memory of the specifics about the various ANAME/BNAME/ALIAS/etc proposals or non-standard features is fuzzy so the following may miss the point (apologies if so, as usual). However, it sounds a bit like what is being proposed in this thread (generally, not in your specific message) is for CNAME to be treated on authority servers like a wildcard RRTYPE for a particular owner name. The response behaviour if a CNAME is present at the owner name matching the QTYPE but there is no corresponding RRTYPE in the zone is to return a NOERROR/CNAME response instead of a NODATA response. For recursive servers the change that is required is to keep track of what QTYPEs triggered particular CNAMEs in the cache so that new-QTYPE cache misses trigger an upstream query. All of this needs to be extended along the edns-client-subnet axis. All of the corner cases relating to existing CNAME behaviour, both standardised and not, on recursive servers, stub resolvers and authority servers needs to be specified. This sounds like a lot of work and likely to cause camel indigestion. However assuming the initial thesis was correct and there is demand for this functionality (seems right to me) using a new RRTYPE for this still sounds easier than changing the semantics of CNAME. Perhaps the new RRTYPE could include an encoding of explicit types that do exist to make life easier for resolvers. Perhaps we could call the RRTYPE "*" instead of ENAME or FNAME to avoid encouraging future GNAME and HNAME proposals :-) Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
