on 30-Oct-2019 21:20
Welcome to my first article on DevCentral! This article starts a series about BIG-IP DNS (the artist formerly known as GTM).
This article and accompanying videos take a look at the support for Domain Name System (DNS) Resource Record (RR) types that were introduced in BIG-IP version 12.0. This enhancement represented a major step forward in the capabilities available on the BIG-IP.
I created these videos during the initial introduction of the feature in BIG-IP 12.0 release. Based on the timestamp in the BIG-IP GUI, that would be October of 2015. The information presented here is still relevant for later versions of BIG-IP and will be of benefit to anyone trying to understand the different DNS resource record types available on the BIG-IP.
The videos assume you have used BIG-IP DNS before, and you understand the basics of DNS. If you need a refresher on DNS resource records, I present an overview of the new and existing resource records supported by BIG-IP DNS. I then go into the feature itself and the architecture and implementation details for each of the records on BIG-IP DNS. In the last video, I do a configuration walk-through of a NAPTR and SRV wideIP along with the NAPTR and SRV pools.
Be sure and see the attachment at the end of the article. It is a zip file that contains a PDF of many of the slides I use in the videos.
First up is the Executive Summary. This video introduces, at a high level, everything that will be covered in the later videos. It also talks about some things that are not explicitly called out in any of the other content.
Next is a DNS technology overview for the different resource record types supported by BIG-IP DNS. If you are already familiar with the different DNS RR types (A, AAAA, CNAME, NAPTR, SRV, MX), you can skip this part. If you need a quick refresher on what each record type is and the fields used in them this content is for you! NOTE: This is not a discussion of how the BIG-IP DNS implements these resource records but rather a discussion of the record types themselves in a purely DNS sense.
If you do not watch any of the other videos in this series, watch these!! I go over the concepts and architecture behind how the different resource records are implemented and configured on BIG-IP DNS with lots of diagrams. The configurations of the different resource record types and all the associated pools can get confusing. These videos will give you a solid foundation to follow the configuration walk-through.
I am going to be bold here and say that I guarantee you will learn something you did not know about BIG-IP DNS if you watch the next five videos. As a polling mechanism, hit the “Like” button on the article if I was correct in my prediction.
This video covers general information about the DNS RR implementation along with the A and AAAA record types. For example, the video talks about a new concept in BIG-IP DNS called Non-Terminal and Terminal Pools and what they mean in wideIP configurations.
This is a long discussion about CNAMEs. Who knew they were so interesting? Well, they are, and it is worth listening to how they are implemented on BIG-IP DNS.
NAPTR, SRV and MX records are next. The configuration walk-through later in this article will implement NAPTR and SRV wideIPs.
Let’s talk about one of the reasons you have a BIG-IP DNS…health checks! Now that wideIPs can be pool member, the game has changed.
Persistence also has some new wrinkles. If you use persistence, you want to watch this.
Finally, we have the configuration walk-through. This is where things get real. In this video, I do a configuration of NAPTR and SRV wideIPs along with the NAPTR and SRV pools. You can see the configuration objects I will create and the order in the diagram below.
That is all I have for this article. I hope you learned something and most importantly have a better understanding of the different DNS resource record types available on the BIG-IP DNS. I have more articles and videos to come so stay tuned. Be sure and grab the attachment if you want a copy of some of the diagrams used in the videos.
Trivia: iQuery uses port 4353 for its communication. Do you know the significance/meaning of that particular port number? Drop a comment at the bottom if you know the answer.
Over the past year, I have often come back to this article, which addresses a part of BIG-IP DNS that frankly I don't think has been well covered anywhere else. In fact, understanding the significant changes made to incorporate the new DNS resource records into wide-IPs and pools with BIG-IP version 12 makes one appreciate why F5 Networks changed the product name from BIG-IP GTM to BIG-IP DNS.
- Thank you for the feedback and thank you to the other commenters as well.
As you mentioned, anyone who used BIG-IP GTM prior to v12 realizes the scope of the change we made to GTM and the subsequent rebranding to BIG-IP DNS.
Did you download the attached zip file? It has many of the PPT slides rendered in a PDF for reference.
Thank @Lee_Orrick for this great article. Can BIG IP DNS Wideip point to AWS ALB/NLB CNAMES as pool members and also can we do health check on them?
@joeldavism thanks for the question and compliment! I must admit I had to go rewatch my own training to remember some things. I am giving you an answer based on my somewhat dated knowledge.
You will be able to configure a static target CNAME as a pool member. It will NOT be eligible for health checking. The BIG-IP will simply return the CNAME to the client with no additional resolution. This is my recollection.
This leads to the obvious follow-up question, "Why?". It is for performance and some security reasons. A terminal pool member is an IP which is, as the name implies, the end. Once you have an IP, there is no more work to do. If we allow an external pool member that is not an IP (terminal pool member) , and we allow health checks there are possible performance impacts. We could spend excessive resources chasing pool member health states against names we do not control. Think of CNAME loops in an external CNAME for example.
I am also going to ask some colleagues to validate my answer because I am not working with BIG-IP DNS on a daily basis anymore. Hope this helps!
This is from the 17.0 docs which echoes what I said above without the additional context. It is always considered available b/c there are not health checks.
static-target Specifies the member's name specifies a static DNAME rather than a name linked to a Wide IP defined on the system. This may be required if the target DNAME is not owned by the organization or configured on GTM. One side- effect of using a static target is that the member is always considered available for load balancing. The default value is no.