Flush dnsmasq cache on IP address failure

[Ramanujam Jagannath]

Backgrounder - Our device connects to an AWS static IP. We use dnsmasq on device to provide lookup services for downstream devices. Currently we are planning to use a long. DNS TTL on AWS to avoid too many DNS lookups from on field devices. The on-field devices use a grpc  connection to maintain long standing tcp connections. We do have multiple availability zones and so a DNS resolution does return 4 IP addresses

Problem - When an IP address fails(on AWS) the grpc client will retry and re-resolve. But because we have dnsmasq on device it will send a cached address - which is potentially faulty. 

Solution - This can be resolved by flushing the dnsmasq cache on device. But is there a way to flush the dnsmasq cache on device on connection failure only? grpc under the hood uses c-ares which in our case goes to the dnsmasq proxy on device.

Any solutions/thoughts. Someone must have encountered this problem before?

[Frédéric Martinsons]

I think this is totally unrelated to grpc but for what it worth, if you control your dnsmasq, you can use --clear-on-reload option and send a SIGHUP to dnsmasq process to reload the cache. 

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/75d68762-eb58-4400-b8e1-3584f6bd6e51n%40googlegroups.com.

[Gmail]

Thanks Frederic

I understand that. But I only want to do it when grpc has a connection failure. Is there an already existing mechanism to do that.?

On Jul 5, 2023, at 12:37 PM, Frédéric Martinsons <frederic....@gmail.com> wrote:



[Richard Belleville]

Depending on which language you're using, you could use the custom name resolver interface to implement this behavior yourself.

[apo...@google.com]

I agree that this seems outside of the scope of the grpc library.

But +1 that you could in theory use a custom name resolver to implement some behavior like this.

Also +1 that the --clear-on-reload plus SIGHUP option may be useful here.

I'm curious though: suppose you can flush the local DNS cache, can you guarantee that there are no more caches upstream?

[Frédéric Martinsons]

Yes, as you tell, if an upstream server have the entry in cache, this will not renew anything until the next ttl expiration.  

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/4a0815f5-f70a-4ee4-8b8c-77e8ea8a7909n%40googlegroups.com.