Skip to content

Instantly share code, notes, and snippets.

@dstanek

dstanek/db.RegionOne.example-cloud.local

Last active October 9, 2015 17:38
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save dstanek/093f851fdea8ebfd893d to your computer and use it in GitHub Desktop.
Save dstanek/093f851fdea8ebfd893d to your computer and use it in GitHub Desktop.
Download ZIP
Raw
db.example-cloud.local
;$TTL 86400
$TTL 10
;@ IN SOA localhost. root.localhost. (
; 1 ; Serial
; 604800 ; Refresh
; 86400 ; Retry
; 2419200 ; Expire
; 86400 ) ; Negative Cache TTL
;
@ IN SOA example-cloud.local. root.localhost. (
1 ; Serial
10 ; Refresh
10 ; Retry
10 ; Expire
10 ) ; Negative Cache TTL
@ IN A 104.239.230.39
IN NS ns.example-cloud.local.
ns IN A 104.239.230.39
; discovery records
b._dns-sd._upd.example-cloud.local 3600 IN PTR @
lb._dns-sd._upd.example-cloud.local 3600 IN PTR @
; region discovery
_os-regions._tcp IN PTR RegionOne.example-cloud.local.
IN PTR RegionTwo.example-cloud.local.
Raw
db.RegionOne.example-cloud.local
;$TTL 86400
$TTL 10
;@ IN SOA example-cloud.local. root.localhost. (
; 1 ; Serial
; 604800 ; Refresh
; 86400 ; Retry
; 2419200 ; Expire
; 86400 ) ; Negative Cache TTL
@ IN SOA RegionOne.example-cloud.local. root.localhost. (
1 ; Serial
10 ; Refresh
10 ; Retry
10 ; Expire
10 ) ; Negative Cache TTL
@ IN A 104.239.230.39
IN NS ns.example-cloud.local.
IN TXT name=RegionOne id=1234
; discovery records
b._dns-sd._upd.example-cloud.local 3600 IN PTR @
lb._dns-sd._upd.example-cloud.local 3600 IN PTR @
; service domains
keystone IN A 104.239.230.39
nova IN A 104.239.230.39
; services for discovery
_os-services._tcp IN PTR _os-identity._tcp
IN PTR _os-compute._tcp
_os-identity._tcp IN PTR public._os-identity._tcp
IN PTR internal._os-identity._tcp
IN PTR admin._os-identity._tcp
IN TXT name=identity type=identity
_os-compute._tcp IN PTR public._os-compute._tcp
IN PTR internal._os-compute._tcp
IN PTR admin._os-compute._tcp
IN TXT name=compute type=compute
; identity endpoints
public._os-identity._tcp IN SRV 0 0 5000 keystone.RegionOne.example-cloud.local.
IN TXT path=/v2.0 region=RegionOne name=public
internal._os-identity._tcp IN SRV 0 0 5000 keystone.RegionOne.example-cloud.local.
IN TXT path=/v2.0 region=RegionOne name=internal
admin._os-identity._tcp IN SRV 0 0 35357 keystone.RegionOne.example-cloud.local.
IN TXT path=/v2.0 region=RegionOne name=admin
; compute endpoints
public._os-compute._tcp IN SRV 0 0 8774 nova.RegionOne.example-cloud.local.
IN TXT path=/v2.1/{project_id} region=RegionOne name=public
internal._os-compute._tcp IN SRV 0 0 8774 nova.RegionOne.example-cloud.local.
IN TXT path=/v2.1/{project_id} region=RegionOne name=internal
admin._os-compute._tcp IN SRV 0 0 8774 nova.RegionOne.example-cloud.local.
IN TXT path=/v2.1/{project_id} region=RegionOne name=admin
Raw
os-dns-sd.asciidoc

OpenStack Service Catalog in DNS

What?

I’m just doing this as a proof of concent, so calm down. How can we put the OpenStack service catalog into DNS? Maybe this is one way…​

This is really me stumbing through learing about DNS while also implementing DNS-Based Service Discovery. It’s possible that I’m looking at this all wrong!

Service types

DNS SRV (RFC 2782) Service Types has a list of the service types and the key/value pairs for their TXT record. These are the service types I have added to facilitate discovery:

  • _os-regions._tcp to discover regions

  • _os-services._tcp to discover services

  • _os-[service type]._tcp for each service (e.g. _os-identity._tcp or _os-compute._tcp)

The service types that represent an OpenStack service have been modeled after the _http._tcp service type.

Discovery

Given a service provider’s cloud example-cloud.local, how can I look at the catalog?

  1. Let’s find some regions

    [source,shell]
----
$ dig +noall +ans _os-regions._tcp.example-cloud.local PTR @104.239.230.39
_os-regions._tcp.example-cloud.local. 10 IN PTR RegionTwo.example-cloud.local.
_os-regions._tcp.example-cloud.local. 10 IN PTR RegionOne.example-cloud.local.
----

  2. Let’s find services in RegionOne

    [source,shell]
----
$ dig +noall +ans _os-services._tcp.RegionOne.example-cloud.local PTR @104.239.230.39
_os-services._tcp.RegionOne.example-cloud.local. 10 IN PTR _os-compute._tcp.RegionOne.example-cloud.local.
_os-services._tcp.RegionOne.example-cloud.local. 10 IN PTR _os-identity._tcp.RegionOne.example-cloud.local.
----

  3. Let’s list the Nova endpoints for RegionOne

    [source,shell]
----
$ dig +noall +ans _os-compute._tcp.RegionOne.example-cloud.local PTR @104.239.230.39
_os-compute._tcp.RegionOne.example-cloud.local. 10 IN PTR adminURL._os-compute._tcp.RegionOne.example-cloud.local.
_os-compute._tcp.RegionOne.example-cloud.local. 10 IN PTR publicURL._os-compute._tcp.RegionOne.example-cloud.local.
_os-compute._tcp.RegionOne.example-cloud.local. 10 IN PTR internalURL._os-compute._tcp.RegionOne.example-cloud.local.
----

  4. Let’s list the details of Nova’s public endpoint in RegionOne

    [source,shell]
----
$ dig +noall +ans publicURL._os-compute._tcp.RegionOne.example-cloud.local SRV @104.239.230.39
publicURL._os-compute._tcp.RegionOne.example-cloud.local. 10 IN SRV 0 0 8774 nova.RegionOne.example-cloud.local.
$ dig +noall +ans publicURL._os-compute._tcp.RegionOne.example-cloud.local TXT @104.239.230.39
publicURL._os-compute._tcp.RegionOne.example-cloud.local. 10 IN TXT "path=/v2.1" "region=RegionOne"
----

  5. Profit? Now we know that in RegionOne the public URL is https://nova.RegionOne.example-cloud.local:8774/v2.1

Getting an endpoint without discovery

If know all the things already you can probably just do step #4?

What has to change in OpenStack?

Probably just the client. Maybe something like this https://review.openstack.org/#/c/232822/ …​ On the other hand that’s terrible looking code :-) I just wanted to prove that this could work.

Using only this small client hack I was able to get openstack client commands for nova and glance working without having to change anything in nova or glance.

There is still much work to be done:

  1. Get rid of the hard coded DNS name

  2. Stop the project/user id catalog substitution

  3. plus lots more…​

Copy link

ghost commented Oct 8, 2015

Word of warning- Don't use BIND. Seriously. It is horrible software which has effectively EOLing itself because BIND10 was canceled and there is no answer to moving BIND9 forward into the 20th century.

Other than that, DNS based service discovery is a great idea with lots of strengths. Replication of the DNS between primary and secondary servers is super powerful and allows you to build a very resilient service with fantastic availability to clients. Tooling to build DNS zone files are abundant and exist for nearly every language I can think of.

Using DNSSEC and other security tools built into the DNS would allow us to verify queries and be sure the data we've fetched is signed and correct from top to bottom. This would require a bit more configuration, but guides and BCPs abound for doing this. Having this assurance would be equivalent to using TLS for HTTP which most people seem to trust to a reasonable extent.

Finally, this could be a good opportunity to work with the Designate folks. I've been in contact with a few of them, and they seem like a great group.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment