Allow fallbackDuration = 0 without disabling fallback

[pimterry]

I want to allow fallback, but never cache any addresses as always using the fallback address.

In my case, that would be useful because I'm using a custom local DNS server that's doing some funky logic (resolving against the currently running set of docker containers) and the addresses that this server can resolve can change very frequently. I want to ensure every single lookup checks my custom DNS server doing running a normal resolution.

Is there a specific reason that this is currently not allowed? For now I'm using 1, which is obviously pretty close and mostly works for my case, but it would be nice if I could disable that caching entirely whilst still using the fallback functionality.

[szmarczak]

I'm using a custom local DNS server that's doing some funky logic (resolving against the currently running set of docker containers) and the addresses that this server can resolve can change very frequently. I want to ensure every single lookup checks my custom DNS server doing running a normal resolution.

You can do https://github.com/szmarczak/cacheable-lookup#servers to make it use your DNS servers by default.

cacheable-lookup/tests/test.js

Lines 455 to 471 in c257b04

	test('custom servers', async t => {
	const cacheable = new CacheableLookup({resolver: createResolver()});
	// .servers (get)
	t.deepEqual(cacheable.servers, ['127.0.0.1']);
	await t.throwsAsync(cacheable.lookupAsync('unique'), {code: 'ENOTFOUND'});
	// .servers (set)
	cacheable.servers = ['127.0.0.1', '192.168.0.100'];
	verify(t, await cacheable.lookupAsync('unique'), {
	address: '127.0.0.1',
	family: 4
	});
	// Verify
	t.deepEqual(cacheable.servers, ['127.0.0.1', '192.168.0.100']);
	});

Is there a specific reason that this is currently not allowed?

Fallback is meant to be used only when you're querying an endpoint defined in your hosts file. Meaning the DNS entry is only available locally. It's not meant to "merge" two servers into one interface.

[pimterry]

You can do szmarczak/cacheable-lookup#servers to make it use your DNS servers by default.

Yep, I'm doing this, like cacheable.servers = [myCustomDockerDns]. That works fine, but that server can only resolve docker container aliases, not external addresses.

Fallback is meant to be used only when you're querying an endpoint defined in your hosts file. Meaning the DNS entry is only available locally. It's not meant to "merge" two servers into one interface.

Is there a specific reason why it can't merge a DNS server with dns.lookup though, or a specific way that that's harmful?

In my case, I'm looking up hosts for traffic from developers debugging their applications, so lots of traffic is localhost, .local MDNS, custom hosts, docker containers, etc etc, rather than normal resolvable domains.

I just want to resolve against my custom dns server before normal dns.lookup, plus add some caching for performance. Except for the fallbackDuration > 0 requirement, this library seems to do that great! It's just 1 extra second of fallback caching away from perfect 😃.

[szmarczak]

Is there a specific reason why it can't merge a DNS server with dns.lookup though, or a specific way that that's harmful?

Wouldn't a better solution be to forward DNS queries to another server if you don't have them defined? For example https://coredns.io/plugins/forward/

In my case, I'm looking up hosts for traffic from developers debugging their applications, so lots of traffic is localhost, .local MDNS, custom hosts, docker containers, etc etc, rather than normal resolvable domains.

What's the reason behind this?

I just want to resolve against my custom dns server before normal dns.lookup, plus add some caching for performance.

I think a better way would be to create another property called fallbackServers. It would call them if the first resolver finds no data. What do you think?

[pimterry]

In my case, I'm looking up hosts for traffic from developers debugging their applications, so lots of traffic is localhost, .local MDNS, custom hosts, docker containers, etc etc, rather than normal resolvable domains.

What's the reason behind this?

My product is a developer tool - all the users are developers (or similar). It's a desktop app, so all of this is running in node on the developers' machines. The app itself is a local proxy for HTTP debugging. I'm trying to customize dns resolution as part of the routing for that, so that I can properly proxy traffic between docker containers, in addition to other developer debugging traffic.

I think a better way would be to create another property called fallbackServers.

This sounds useful in general, but I don't think it will help for my case. I specifically want to fallback to the OS's default DNS resolution, not another DNS server. I don't want to specify a different server because it might resolve things differently than the OS, and AFAIK no DNS resolution except dns.lookup will correctly resolve addresses like localhost, *.local and so on.

Wouldn't a better solution be to forward DNS queries to another server if you don't have them defined?

This could work: my DNS server is also running in node on the same machine, so it could just call dns.lookup instead. That wouldn't have any customizable caching though, so I'd probably want to install cacheable-lookup inside my own DNS server at that point 😃. It's also nicer to keep that little DNS server focused on just one thing: looking up Docker aliases.

I still don't understand why falling back to dns.lookup is bad - I'm super happy to do that almost all the time, I basically must do that.

[szmarczak]

Thank you for the explanation. Finally I understand your thinking, and I agree! I will fix this tomorrow.

[szmarczak]

Released 6.0.0.

[pimterry]

Amazing, thanks for the quick turnaround! Just tested it, seems to work perfectly 👍