Resolution of domain names for sub domains seems to match erroneous DNS

[jonathanKingston]

For example the domain:
https://www.ssllabs.com/ssltest/analyze.html?d=portal.cyber-ami.com&latest

There is a record for www.portal.cyber-ami.com which gets picked up by the DNS matching rules on the scan (Which in my opinion it shouldn't).

The API also never resolves a result for this subdomain and the subdomain isn't visible in the API response which the API consumer can only assume the site has broken DNS for one of its servers.

[selecadm]

@ivanr, please disable WWW resolution for subdomains. This behaviour looks illogical to me.

[ivanr]

@jonathanKingston I think you should be able to resolve this problem by examining the "delegation" field. First, you need to determine if the exact hostname you're interested in has the prefix. Then, you ignore all endpoints that don't match your case. In your example, there's no prefix, so you should ignore endpoints that don't have delegation bit 1 set. (In other words, delegation should be 1.)
By the way, can you get from the browser the IP address it's using to connect to the web site? It strikes me that, because of georesolution, SSL labs might not be able to "see" the same IP address and thus might not be able to test the exact server the browser is connecting to.

[ivanr]

@selecadm If it's in DNS, I think it's fair to assess it :)

[jonathanKingston]

@ivanr thanks for the delegation field help.

I can get the IP sometimes will look further into the reliability of this; however not sure how much weight I want to give to it as load balanced servers won't always be the same IP.

Out of interest is there a lot of cases where SSL Labs are unable to access IP addresses?

[ivanr]

The idea is that, if you know the IP address, SSL Labs will give you the configuration of the same server that the browser is connecting to. (Except when anycast is used, but that can't be avoided.)
Any service that uses georesolution will give only region-local addresses to SSL Labs. I don't know how many of those there are.

[drwetter]

Hi Ivan,

For me it looks also strange to look also for www.DOMAIN -- if just DOMAIN was supplied. Sounds to me machine wants to be smarter than my instruction. Not sure whether I like that (to be honest: no)

Maybe it was common sense like 15 years ago that a domain (attention: sarcasm) "has to have www" otherwise this felt somehow wrong -- (attention: arrogance) at least for people just started using the internet. But nowadays?

If there's no RFC or a draft I would rather stick on the input supplied instead of scanning other IPs too or stating "Prefix handling Not valid for "www.DOMAIN" CONFUSING.

Cheers, Dirk

[selecadm]

@drwetter A-record for WWW seems to be needed only for housewives and elderlies who use Google to open Facebook.

Good practice is either redirecting WWW.example.com to example.com or just not resolving WWW at all.

Certificates for my sites are valid for WWW only if:

1. It is a wildcard.
2. It is Comodo that puts WWW in SAN without even asking.

StartCom requires to submit a subdomain, so I have to use something like "secure" or "generic-san", so that the cert is not valid for WWW.

Good:

Prefix handling Non-prefixed access only, but DNS not configured for prefix

Bad:

Prefix handling Both (with and without WWW)