Re: [DNSOP] Redefining name canonicalization

[Bob Harold <[e-mail]>]

On Thu, Apr 13, 2017 at 5:29 AM, Florian Weimer <[e-mail]> wrote:

> I would like to propose the restrict name canonicalization (as performed
> by stub resolvers) to forming a fully-qualified domain name with the help
> of the search list.
>
> With the current rules based on resolving CNAME chains, we end up with the
> following results:
>
> >>> socket.getfqdn('access.redhat.com')
> 'a23-214-169-56.deploy.static.akamaitechnologies.com'
> >>> socket.getfqdn('access')
> 'a23-214-169-56.deploy.static.akamaitechnologies.com'
>
> This is pretty much useless.  In fact, what is advertised here as the
> canonical name is just a temporary, location-dependent name which bears no
> direct relationship to the service being provided.  There isn't anything
> canonical about it.
>
> I think both calls should return 'access.redhat.com' (assuming that '
> redhat.com' is the search list entry which is used to form the FQDN).
>
> This also avoids issues related to insecure name canonicalization (based
> on spoofable DNS data) which affects the use of some cryptographic
> libraries, notably Kerberos.
>
> Comments?
>
> Thanks,
> Florian
>
>
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

-- 
Bob Harold