Replace DNS lookup with DNS resolve

[potemkin_ai]

Currently Cloudron do DNS A entry lookup with domain configured as a wildcard, which has no practical sense.

I might have wildcard domain configuration as well on DNS provider side and it works like a charm.

Solely for Cloudron I have to create A DNS records, just to let them be deleted afterwards.

I can see no practical reason to verify A record existence, as it brakes abstraction layer - you don't need to know if A record is there, you are verifying if name could be resolved.

It also feels like that check shall be done before any reconfiguration, not at the end of it - leaving process hanging, while system administrator adjust things.

[girish]

@potemkin_ai said in Replace DNS lookup with DNS resolve:

you don't need to know if A record is there, you are verifying if name could be resolved.

This is what it does currently With wildcard provider, in fact, there is no way to check if there is a real A record. You can only check if the DNS resolves.

[potemkin_ai]

@girish for some reason it fails, unless I create an appropriate A record.

if that's not too much to ask, may I ask you for the code snippet? I will think of the ways to see where it might not work or when I miss something (with the later more probable, I would say).

[girish]

@potemkin_ai sure. the https://git.cloudron.io/cloudron/box/-/blob/master/src/dns/wildcard.js?ref_type=heads#L67 is the wait logic which calls into https://git.cloudron.io/cloudron/box/-/blob/master/src/dns/waitfordns.js?ref_type=heads#L85 . the waitfordns.js is essentially host -t A app.domain.com

[potemkin_ai]

@girish thank you!

From the code it seems like I was kind of right then - you specifically check an existence of A record, instead of if the entry could be resolved.

Let me illustrate that the following example:
A entry with * pointing to smth

will lead to the following command to succeed:

host anything-at-all.domain.com

but the following command to fail:

host -t A anything-at-all.domain.com

Because anything-at-all entry doesn't exist. But it will be resolved, thanks to wildcard entry.

Please, let me know if you believe I might be missing something here.

[nebulon]

From a DNS query perspective this will still report an A record type in this case, even though the server will match the wildcard. Wildcard entries may also be of other types like MX.

[potemkin_ai]

@nebulon it seems like some difference exists though...

I tried to check the code, kindly references by girish, but I realized it's a task for a few hours at least, as the logic depends on the provider.

There is a thing I'm not sure I follow: why requesting A record anyway? You just need to ensure the DNS entry is resolve-able, without getting under the hood - it feels like braking the abstraction level here, unless I'm missing something, for sure.

[nebulon]

I am not sure I am following your question here. Resolving the A record type is the same as resolving the domain for the usecase of ipv4 there is nothing special in Cloudron besides just trying to resolve the domain.

[potemkin_ai]

@nebulon to be honest I'm not sure neither now. But for some reason, quite a few times I had to create specific A entry to have DNS resolving to finish. And that is with wildcard entry existing for a few months now.

Is there something I can grab and share with you next time I will encounter that?

[nebulon]

Since wildcard essentially is a feature of the nameserver not the DNS clients querying, I guess if you hit this issue again, you have to talk to your nameserver provider, why the wildcard is not hit.

[potemkin_ai]

@nebulon something is slipping out here...

If it works from host abra-ka-da-bra.mydomain.com command, but does not from Cloudron - isn't it something specific to Cloudron implementation?