On Tue, Jun 19, 2018 at 07:59:34AM -0700, Joe Abley 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.
I concur that allowing some form of redirection alongside other
records is a valuable generalization that seems more natural than
ANAME kludges on the authoritative server.
> 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.
Yes, precisely, a default redirection answer when it would otherwise
have been NODATA. If the RRtype in question is "XNAME" for some
value of "XNAME", then with:
example.com. IN SOA ns1.example.com. root.example.com. ...
example.com. IN NS ns1.example.com.
example.com. IN MX 0 smtp.example.com.
example.com. IN NSEC ... SOA NS MX FOONAME NSEC RRSIG
example.com. IN XNAME www.provider.net.
;
example.com. IN RRSIG SOA ...
example.com. IN RRSIG NS ...
example.com. IN RRSIG MX ...
example.com. IN RRSIG FOONAME ...
example.com. IN RRSIG NSEC ...
You get the SOA/NS/MX/NSEC/XNAME records when asking for one of
those, but otherwise you get the XNAME record along with the NSEC
bitmap proving the non-existence of the requested type.
> 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.
Yes, but if they have the NSEC bitmap, they can follow the XNAME
without asking again.
> All of this needs to be extended along the edns-client-subnet axis.
I am not convinced that ends-client-subnet should be in scope here.
Should there really be a different list of RRtypes per client
subnet? Or just variation in the payload of the same set of RRsets.
It would be far simpler to say that NODATA/NXDomain and the type
bitmap should be global across all client subnets. All you get
per client subnet is payload variation per RRset.
> 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.
Yes.
> This sounds like a lot of work and likely to cause camel indigestion.
Yes, but IMHO cleaner than ANAME, and solves a more general problem.
> 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.
This is where a more detailed pros/cons analysis is needed. The
main advantage of sticking with (modified) CNAMEs is that they will
already be understood by applications. It is unclear to me how
XNAME works.
We're trying to meet application needs, and if this can be made to
work by updating CNAME to allow co-existence with other records
(not just at the zone apex, but more generally), then that would
be a much better fit with existing applications.
> Perhaps the new RRTYPE could include an encoding of explicit types
> that do exist to make life easier for resolvers.
That's already handled by NSEC/NSEC3.
> Perhaps we could call the RRTYPE "*" instead of ENAME or FNAME to
> avoid encouraging future GNAME and HNAME proposals :-)
If it is not CNAME, then the WG will have to bikeshed a name, but
"*" I think invites trouble, various interfaces that expect RRtype
names to look like an alphanumeric identifier would choke on "*".
--
Viktor.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
