Ray Bellis wrote: > > I don't think that either SRV or URI are usable for the primary use > case, i.e. allowing a domain owner to put a record at the apex of > their zone that points at the hostname of the web provider they want to > use. > >
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. Is knowing when something is (or is at least expected to be) the apex, one of the fundamental drivers on this issue? Is the question of how the "effective TLD list" is maintained, published, integrated, etc., something we could/should look closer at, or is that a big can of worms we should stay away from? E.g. get it published by IANA, through multiple mechanisms, and formalize the update to it through the TLD/registry creation process at ICANN? Is it necessary to change/improve the process, publication, ownership, etc. in order for browsers to reply on it at a protocol level? I.e. Rather than rely on hunting for SOA records in DNS and/or looking for NSes for zone cuts, is making a first pass determination by looking at whether the "authority" of the URI, aka the FQDN, is one level below an "effective TLD"? If I have "example.com" or "example.co.jp", or " example.com.au", and I have the current, comprehensive list of places someone can register domains, I know that in those cases, "example" is an apex name. Or does the solution to this problem need to handle apex names for internal-to-a-registrant zone cuts? Use of ETLDs could drive the initial query to be some new record type that exists at a zone apex. (The ETLD list gives an answer to "is it the apex" which is either "yes" or "maybe", because zone cuts below the ETLD+1 level can exist, obviously.) 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? (The distinction between a self-referential or empty RDATA answer, and a NOERROR/NODATA lack of RR, would be the indicator on whether the zone owner wanted to play nice with the optimizations. The client would probably also need to do separate A/AAAA queries in the NOERROR/NODATA case, since the triggering URI would still need to its authority name to be resolved to an address.) I.e. : @ NEWRRTYPE @ ; (or empty RDATA, signaling that the response needs to include A/AAAA, and that the client should expect A/AAAA in the response) @ A <apex IPv4> @ AAAA <apex IPv6> or @ NEWRRTYPE www.myproviders.fqdn ; points out of zone, so no additional data -- but client/recursive needs to chase RDATA down like it was a CNAME I realize in this hypothetical model, both authority and recursive servers need updates. Or is the returning A/AAAA on the empty/self-ref a strictly optional optimization, and thus not a barrier to adoption? (The client can't do a parallel query for the A/AAAA records, because it needs the first answer to get the name for the second query. But it can do the queries sequentially without the assistance of the recursive.) I anticipate both the new record type and additional processing, would be less problematic on authority operators than ANAME. It adds more additional processing, but does not change the general model of mostly-static zone data, which plays nice with DNSSEC. 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.) Also: would this new record type (and query/response logic) make sense to use everywhere, not just at a zone apex? 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. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
