On Sat, Jun 23, 2018 at 07:43:19PM -0700, Joe Abley wrote:
> > Yes, but if they have the NSEC bitmap, they can follow the XNAME
> > without asking again.
> > [...]
> > That's already handled by NSEC/NSEC3.
>
> I think a pragmatic solution needs to work in unsigned zones.
For unsigned zones a synthetic NSEC record can (and should) be
returned unsigned,
example.com. IN "XNAME" www.example.net.
example.com. IN NSEC \0.example.com. SOA NS MX "XNAME"
> If an XNAME proposal was to solve real-world problems for these people
> it would need to work with or without DNSSEC.
> [...]
> (And I wasn't entirely serious about calling the wildcard RRTYPE * :-)
Good, but actually, for "XNAME" to solve real-world problems, what's
needed is XNAME == CNAME. Anything else faces deployment hurdles,
as applications have to be updated to support the new record.
CNAMEs are already understood, so just generalize them to be a
fallback redirect for RRtypes not explicitly configured.
On Sun, Jun 24, 2018 at 04:36:50AM +, Evan Hunt wrote:
> > I think a pragmatic solution needs to work in unsigned zones.
>
> +1, but, an unsigned zone could still return an NSEC-style bitmap. It
> wouldn't be provably correct, but neither is any other unsigned response.
Agreed.
> You could actually add the bitmap to the XNAME rdata, instead of returning
> an NSEC.
But that requires a new "XNAME" rrtype, whereas what the users want
is a more flexible CNAME that coëxists with other RRtypes. And
so in the unsigned case, an NSEC RR can ride along to provide the
information that the CNAME is of the new kind that lives alongside
some other records.
> The XNAME could then mean "alias to for any rrtype not in
> ".
I think that's the more appropriate definition. Anything else
would require considerable new machinery.
> In any case, I don't understand how XNAME avoids the "ANAME kludges".
> Legacy resolvers won't know what to do with XNAME, so all the same
> workarounds on the auth side still must be implemented.
By making: XNAME == CNAME.
--
Viktor.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
