Has Circle CI changed resolution behaviour for .dev domain recently?

Build Environment
1

I have a build process which is now (since Feb 4 UTC+11:00) failing because the domain:

 database.acme.dev

is not resolving to a host interface. If I try to re-run builds that were successful on Friday, these builds now fail for the same reason - database.acme.dev does not resolve.

Locally, we use the ruudud/devdns docker image to achieve this resolution, but in the Circle CI build there are parts of the build that were successfully resolving database.acme.dev even when that container had not been started, indicating that previously some other component was performing resolution for *.dev.

As far as I can tell, the only way our build process previously worked was if the Circle CI environment was resolving *.dev to the local interface prior to Feb 4, but since Feb 4 no longer does this. This would explain why my builds were working prior to Feb 4, but not after that time.

I plan to fix our build processes so that it isn’t reliant on the environment to resolve *.dev, but I am curious to know (to verify my diagnosis) whether Circle CI had previously resolved *.dev and no longer does.

2 Likes
2

Ok, I think the explanation is here:

https://hn.svelte.technology/item/15862770

In summary, I think this is what happened.

Back in 2015, Google purchased the .dev domain. As required by ICANN’s controlled interruption procedures, they introduced a wildcard which mapped everything to the 127.0.53.53 dummy address.

My build was (unknowingly) relying on this default resolution but Google has since removed the wildcard resolution (sometime between Feb 2 and Feb 4) so that it no longer works.

edit: I am not 100% sure Google removed wild card resolution between Feb 2 and Feb 4 - perhaps it was removed earlier and something in the Circle CI environment was compensating after that removal. Either way, the resolution appeared to stop working between Feb 2 and Feb 4.

1 Like