Skip to content

Add cache for CNAME mappings resolved during lookup of DNS entries.#8314

Merged
normanmaurer merged 2 commits into4.1from
cname_cache
Sep 27, 2018
Merged

Add cache for CNAME mappings resolved during lookup of DNS entries.#8314
normanmaurer merged 2 commits into4.1from
cname_cache

Conversation

@normanmaurer
Copy link
Copy Markdown
Member

Motivation:

If the CNAMEd hostname is backed by load balancing component, typically the final A or AAAA DNS records have small TTL. However, the CNAME record itself is setup with longer TTL.

For example:

  • x.netty.io could be CNAMEd to y.netty.io with TTL of 5 min
  • A / AAAA records for y.netty.io has a TTL of 0.5 min

In current Netty implementation, original hostname is saved in resolved cached with the TTL of final A / AAAA records. When that cache entry expires, Netty recursive resolver sends at least two queries — 1st one to be resolved as CNAME record and the 2nd one to resolve the hostname in CNAME record.
If CNAME record was cached, only the 2nd query would be needed most of the time. 1st query would be needed less frequently.

Modifications:

Add a new CnameCache that will be used to cache CNAMEs and so may reduce queries.

Result:

Less queries needed when CNAME is used.

@normanmaurer
Copy link
Copy Markdown
Member Author

Also /cc @slandelle @vietj

Motivation:

If the CNAMEd hostname is backed by load balancing component, typically the final A or AAAA DNS records have small TTL. However, the CNAME record itself is setup with longer TTL.

For example:
* x.netty.io could be CNAMEd to y.netty.io with TTL of 5 min
* A / AAAA records for y.netty.io has a TTL of 0.5 min

In current Netty implementation, original hostname is saved in resolved cached with the TTL of final A / AAAA records. When that cache entry expires, Netty recursive resolver sends at least two queries — 1st one to be resolved as CNAME record and the 2nd one to resolve the hostname in CNAME record.
If CNAME record was cached, only the 2nd query would be needed most of the time. 1st query would be needed less frequently.

Modifications:

Add a new CnameCache that will be used to cache CNAMEs and so may reduce queries.

Result:

Less queries needed when CNAME is used.
Copy link
Copy Markdown
Member

@trustin trustin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just 2 nits

* A cache for {@code CNAME}s.
*/
@UnstableApi
public interface CnameCache {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DnsCnameCache? Not strong on this though.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure why not...

}

/**
* Returns the cname cache.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • cname cache -> {@link CnameCache}?

@normanmaurer
Copy link
Copy Markdown
Member Author

@trustin addressed.

@normanmaurer normanmaurer merged commit 5650db5 into 4.1 Sep 27, 2018
@normanmaurer normanmaurer deleted the cname_cache branch January 22, 2019 10:28
normanmaurer added a commit that referenced this pull request May 8, 2020
Motivation:

In netty there is a seperate CNAME cache that is used to cache CNAMEs that are resolved during resolving an A / AAAA record. While this sounded like a great idea when I first implemented this in netty it turned out this is problematic and may produce errors while resolving hostnames later on.
The problem with the CNAME cache is that we may end up with entries in the CNAME cache wile the original cached resolution was already removed from the cache (due TTL). In this case we may find an entry in teh CNAME cache that we will then try to resolve via the specified nameserver. This resolution may fail as the nameserver may not return an entry for the previous cached CNAME. This usually happens when we receive the full "resolution chain" during query for an A / AAAA record.

This problem was introduced by #8314

Modifications:

- Use the NoopDnsCnameCache by default
- Deprecate methods that allow to set a custom DnsCnameCache
- Deprecate DnsCnameCache and all the implementations
- Add unit test

Result:

Fixes resolution problem caused by cached cname records
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants