On 04/11/2018 18:16, Brian Dickson wrote:
Is the apex thing an optimization only (i.e. is it acceptable that
the mechanism for apex detection not be 100% effective)? I think
that's the input needed before it makes sense to go down any
particular branch of design work, by either the http folks or the dns
folks.
It's not a question of apex *detection*, it's that DNS simply doesn't
allow for the *provisioning* of a CNAME record at the apex.
Nor can you put a CNAME alongside any other "useful" DNS records, so you
can't, for example, have a zone that looks like this:
$ORIGIN example.com
@ IN SOA ...
IN NS ...
company-division IN MX <company mail system>
company-division IN CNAME <cdn web host>
[I should perhaps put that as an example in the draft]
Is knowing when something is (or is at least expected to be) the
apex, one of the fundamental drivers on this issue?
No, the mechanism is general purpose and could be used for any
domain name that requires redirection (at the DNS / hostname level) to a
hostname that does not match the domain name in the URI.
[snipping irrelvant stuff about effective TLD lists]
Related, follow-on question: If that new record type were pointing to
the owner name (i.e. itself), or otherwise signaled that an A/AAAA at
the owner name should be used, would having the authority server
return the A/AAAA records as well fix the multiple-lookups issue,
i.e. not require the lookup of the A/AAAA records if the new record
type was not present?
Although it's not documented as such yet (and I should, because it's an
important clarifaction) an HTTP record that points to itself would be an
error, in the same way that a CNAME loop would be.
Architecturally, the important part of my proposal is that resolution of
the A and AAAA records is done *at the recursive layer* of the DNS, with
no interference with how authoritative resolution works.
[the only exception is if EDNS Client Subnet is in use, but that's a
case where the authoritatives already know how to generate the right
answer for any particular subnet]
[snippage]
I anticipate both the new record type and additional processing,
would be less problematic on authority operators than ANAME.
The new record type has *no* implications at all for authority operators
other than in their provision systems, and since it uses the same RDATA
format as a PTR or CNAME record the implications there should be minimal.
It adds more additional processing, but does not change the general
model of mostly-static zone data, which plays nice with DNSSEC.
There's *no* additional processing done in authoritatives. I suppose
theoretically if the target happens to be on the same server as the
owner name than an authority might also include the A and AAAA records,
but it's not specified that way at the moment.
For the recursives, the incremental change is the same additional
processing as authority servers (additional data if empty/self-ref,
possibly with extra queries, or CNAME-type processing.)
Roughly, except per above, this is the *only* incremental change in the
DNS infrastructure. The other necessary change is in the HTTP clients
themselves, which IMHO is how it should be.
Also: would this new record type (and query/response logic) make
sense to use everywhere, not just at a zone apex?
Yes, per above.
I think there would be nothing implicitly difficult in making it
universal, on both the authority and recursive servers. For the
recursive servers, I don't think they even have the ability to
distinguish whether a name is apex or not (!!). For authorities, I
don't think there's anything intrinsically apex-ish about what is
required, so it would probably be less work to support the new record
type anywhere.
It's not apex specific at all, but its design is specifically intended
to address the CNAME at the apex issue.
kind regards,
Ray
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
