In message <[email protected]>, Florian Weimer wr ites: > On 04/21/2017 05:08 PM, Bob Harold wrote: > > > I can understand you wanting a "getfqdn" function to return the FQDN > (fully > > qualified domain name) without doing canonicalization. > > > > But just so we are clear on the DNS terms, > > "access.redhat.com" and "access.redhat.com.edgekey.net" are "aliases" > > "e133.b.akamaiedge.net" is the canonical name. > > > > access.redhat.com is an alias for access.redhat.com.edgekey.net. > > access.redhat.com.edgekey.net is an alias for e133.b.akamaiedge.net. > > e133.b.akamaiedge.net has address 104.67.69.246 > > I'm aware of the terminology. > > I just think that in terms of RFC 3493, it would make sense to restrict > the name transformation applied with AI_CANONNAME on the current > internet, i.e. clarify that here > > If the AI_CANONNAME flag is specified and the nodename argument is > not null, the function shall attempt to determine the canonical name > corresponding to nodename (for example, if nodename is an alias or > shorthand notation for a complete name). > > alias does not refer to CNAME chain resolution, but other forms of > alias processing (like the slightly historic HOSTALIASES processing).
It does mean the end of the CNAME chain. Just because some people misuse CNAME rather than requesting their own type to provide a name to server mapping or using SRV that we should change what the flag means. > This would help to address long-standing security issues in name > canonicalization, e.g. in Kerberos deployments. If you want the search name, then add a flag to request that and extend struct addrinfo by adding a pointer at then end of it which contains the resolution of the search. Yes, sometimes the contents of ai_canonname will be the same as ai_<to_be_decided> and sometimes not. getaddrinfo and struct addrinfo are designed to be extended like this. Don't redefine the existing element. Mark > Thanks, > Florian > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
