This opens the can of worms that is DNS caching. On one end of the spectrum, you can always perform a full DNS lookup of a target and never store the result. If the result of the lookup changes, then you will know about it as soon as possible. However, the repeated DNS lookups are very expensive, and most of the time, those lookups will be redundant.
On the other end of the spectrum, you can look up a target once and cache the result forever. It is much less expensive since you only ever do one DNS lookup, but if the DNS record ever changes, you will send traffic to the wrong address. Usually what works best is some middle ground. Essentially, cache the result of a DNS lookup for some configured time. After that time is up, perform the lookup again. It's a compromise. You don't have to perform lookups as often, which is good. However, most of the lookups you still perform will be redundant since it is unlikely that results will change. And if the address does change, then you will not detect it until the current cached result is stale. Having said all that, caching is hard. If we can avoid having to do it ourselves, that's a good thing. One way to go with this is to go with the extreme of always performing DNS lookups. We can then recommend that users of OVS that will be performing frequent DNS lookups also run a DNS forwarder that has built-in caching (as well as negative caching. That's another headache). That separates concerns more evenly. Anyways, that's just my opinion. If you decide that a DNS caching layer in OVS is appropriate, then that's fine too. Mark On Thu, Oct 26, 2017 at 5:14 PM Yifeng Sun <pkusunyif...@gmail.com> wrote: > Thanks Mark for your reply. > > There is one more thing. If we bring DNS into play, we may need a > mechanism to watch for changes of ip addresses that were already resolved > and being used. > > Thanks, > Yifeng > > On Thu, Oct 26, 2017 at 12:10 PM, Mark Michelson <mmich...@redhat.com> > wrote: > >> On Wed, Oct 25, 2017 at 4:16 PM Yifeng Sun <pkusunyif...@gmail.com> >> wrote: >> >>> I feel that unbound stands out in the available open source DNS resolver. >>> >>> Below is the summary for unbound: >>> * The actual resolving work is done by a background process or thread. A >>> background process or thread seems unavoidable. Linux's getaddrinfo_a >>> clones a thread similarly. >>> >> * It is ported on Linux, BSD, Windows, MacOS/X and Solaris/SPARC. This is >>> good because OVS runs on a large range of platforms. >>> >> * It complies to the standard, with optional DNSSEC support. Some of its >>> features may not be needed in our case. >>> * The unbound context is thread-safe. Its internal locks may bring some >>> overhead. But since the DNS resolving is not frequent in OVS, I suppose >>> this small overhead is not an issue. >>> >>> Unbound looks like a good option. Another option is to create a >>> background thread which processes DNS resolving requests from the main >>> thread and sends back the resulting events to the main thread. This method >>> is quite simple and straightforward. >>> >>> The above are what I got so far. Please give your thoughts, thanks a lot. >>> >> >> If portability to all of the systems you mentioned in your second bullet >> point is important, then you can rule out a couple of options: >> * getaddrinfo_a is a GNU extension and is only available with glibc >> * The resolver functions[1] are a BSD specification so they'd be >> available on most platforms, but not on Windows. I don't personally >> recommend these because of the need to manually parse the DNS responses you >> receive. >> >> That leaves two options: >> * Run a background thread uses getaddrinfo() to perform resolution. >> * Use a third-party library (like unbound). >> >> Of these two options, I feel like the third-party library is the better >> option. The only downside I can think of is the extra dependency for OVS. >> And as far as what third-party library to use, I was the one that suggested >> unbound in the first place, so obviously I'm fine with using it :) >> >> Mark >> >> [1] http://man7.org/linux/man-pages/man3/resolver.3.html >> >> >>> >>> Below is the link for original discussion: >>> https://mail.openvswitch.org/pipermail/ovs-dev/2017-August/337038.html >>> >>> >>> >>> On Wed, Oct 25, 2017 at 2:11 PM, Ben Pfaff <b...@ovn.org> wrote: >>> >>>> Hello everyone, please allow me to introduce Yifeng Sun (CCed), who >>>> recently joined VMware's Open vSwitch team. I've asked Yifeng to start >>>> out by working on DNS support for Open vSwitch. Yifeng, can you tell us >>>> about what you've discovered so far, based on this thread from August >>>> that I'm reviving, and your tentative conclusions? >>>> >>>> Thanks, >>>> >>>> Ben. >>>> >>> >>> > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev