{"id":19988,"date":"2023-01-20T05:57:13","date_gmt":"2023-01-20T05:57:13","guid":{"rendered":"https:\/\/www.booksofall.com\/es\/?post_type=product&p=19988"},"modified":"2023-01-26T06:41:35","modified_gmt":"2023-01-26T06:41:35","slug":"designate-documentation","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/es\/designate-documentation\/","title":{"rendered":"Designate Documentation"},"content":{"rendered":"

Designate is a multi-tenant DNSaaS<\/a> service for OpenStack<\/a>. It provides a REST API with integrated Keystone authentication. It can be configured to auto-generate records based on Nova and Neutron actions. Designate supports a variety of DNS servers including Bind9 and PowerDNS 4.<\/p>\n

Introduction to Designate<\/b><\/h2>\n

Designate is an Open Source DNS-as-a-Service implementation and a part of the OpenStack ecosystem of services for running clouds. In order to understand what Designate can do and how it works, its necessary to understand some of the basics of DNS.<\/p>\n

What is DNS? <\/b><\/h3>\n

The Domain Name System<\/a> (DNS) is a system for naming resources connected to a network, and works by storing various types of\u00a0record<\/i>, such as an IP address associated with a domain name. In practice, this is implemented by\u00a0authoritative name servers\u00a0<\/i>which contain these records and\u00a0resolvers\u00a0<\/i>which query name servers for records. Names are divided up into a hierarchy of zones, allowing different name servers to be responsible for separate groups of zones by delegating responsibility using records.<\/p>\n

The root zone, which is simply ., is comprised entirely of records delegating various top level domains<\/a> (TLDs) to other nameservers. The TLD name servers will contain records for domains within their TLD, such as the\u00a0.com\u00a0<\/i>nameserver having an\u00a0example.com\u00a0<\/i>record, as well as records that delegate zones to other nameservers, for example\u00a0openstack.org\u00a0<\/i>might have their own nameserver so that they can then create\u00a0cloud.openstack.org<\/i>.<\/p>\n

Resolvers\u00a0<\/i>are often formed in two parts: a\u00a0stub\u00a0<\/i>resolver which is often merely a library on a users computer, and a recursive resolver\u00a0<\/i>that will perform queries against nameservers before returning the result to the user. When searching for a domain, the resolver will start at the end of the domain and work its way back to the beginning.<\/p>\n

For example in the diagram below, when searching for cloud.openstack.org, it will start with the root nameserver ., which will reply with the location of the .org nameserver. The resolver can then contact the .org nameserver to get the openstack.org nameserver and from there finally get the cloud.openstack.org record and return it to the user.<\/p>\n

In order to make this more efficient, the results are cached on the resolver, so after the first user has requested cloud.openstack.org, the resolver can return the cached result for subsequent requests.<\/p>\n

Further reading on DNS and how it works is available here:<\/b><\/p>\n