Portal:Cloud VPS/Admin/DNS

From Wikitech
Jump to navigation Jump to search

This page contains information about how DNS domains are setup in Cloud VPS and Toolforge.

Domain names


Naming for openstack API endpoints and other shared service endpoints like elasticsearch. Subdomains may be added as needed to differentiate services and service regions/zones/clusters.

  • openstack.eqiad1.wikimediacloud.org
  • cloudinstances2b-gw.openstack.codfw1dev.wikimediacloud.org
  • nat.openstack.eqiad1.wikimediacloud.org

Zone data (records) are stored and served by prod DNS servers, managed using operations/dns.git. Subdomains may be delegated to OpenStack Designate when appropriate.


Naming for public exposure of Cloud VPS instances either directly (public IPv4/IPv6) or via proxy (HTTPS proxies). Replaces deprecated *.wmflabs.org

  • bastion.wmcloud.org
  • space.wmcloud.org
  • outreachdashboard.wmcloud.org
  • bastion.tools.wmcloud.org

Since the bare wmcloud.org domain is assumend to reference stuff running in eqiad1, this domain is hosted by Designate @ eqiad1, and it belongs to the cloudinfra project. Data in this domain is managed using Horizon and/or the CLI.

There is a also a per-deployment subdomain.

  • codfw1dev.wmcloud.org: for stuff running in that deployment, domain hosted by Designate @ codfw1dev, belongs to the cloudinfra-codfw1dev project.
  • eqiad1.wmcloud.org. Not in use, because wmcloud.org is just a shortcut.

If project-specific subdomains are introduced, they should belong to their own projects. Example:

  • database01.clouddb-services.wmcloud.org. A public proxy / floating IP for a database in the clouddb-services project in eqiad1.
  • bastion-01.bastion.codfw1dev.wmcloud.org. A floating IP for a bastion server in the bastion project in codfw1dev.

In the example above, both records would have been created by hand by the projectadmins in their corresponding projects, using Horizon or the CLI.


Naming for internal Cloud VPS instances and services. Intended for private IP addresses. Replaces deprecated *.{data center}.wmflabs

  • bastion-01.bastion.eqiad1.wikimedia.cloud
  • k8s-control.svc.tools.eqiad1.wikimedia.cloud
  • enwiki.analytics.db.svc.wikimedia.cloud

The main domain (wikimedia.cloud) data is stored and served by prod DNS servers, managed using operations/dns.git. Then, a delegation exists per deployment:

  • eqiad1.wikimedia.cloud: delegated to Designate @ eqiad1
  • codfw1dev.wikimedia.cloud: delegated to Designate @ codfw1dev

Inside openstack, this deployment-specific domain belongs to the cloudinfra project.

Then, project-specific subdomains exist and belong to each project. These subdomains are automatically created via keystone hooks:

  • tools.eqiad1.wikimedia.cloud: belongs to the tools project, data served by Designate @ eqiad1
  • mytest.codfw1dev.wikimedia.cloud: belongs to the mytest project, data served by Designate @ codfw1dev

Records in this project-specific subdomain are managed automatically at VM instance creation/deletion time, and otherwise with Horizon/CLI.

A special service subdomain svc might exists to hold service addresses specific to each project:

  • k8s.svc.tools.eqiad1.wikimedia.cloud: FQDN endpoint for the k8s api-server.

Since these aren't floating IPs, but an alias to VM instance addr, these records are created by hand using Horizon or the CLI.


This domain is dedicated to represent physical datacenter network cloud-realm subnet/VLAN addresses, such as cloud-private.

The primary usage is for hardware servers that have an IP in such subnet/VLAN, similar to <server>.<datacenter>.wmnet.

Like the main domain (wikimedia.cloud), data is stored and served by prod DNS servers, managed using operations/dns.git, mostly because the FQDNs here could be required for the cloud itself to work (so, to avoid chicken-eggs problems).

Examples, servers that would have 2 IP addresses and 2 FQDNs:

  • cloudcontrol1003.private.eqiad.wikimedia.cloud and cloudcontrol1003.eqiad.wmnet.
  • cloudlb2001-dev.private.codfw.wikimedia.cloud and cloudlb2001-dev.codfw.wmnet.

This was decided in Wikimedia_Cloud_Services_team/EnhancementProposals/Decision_record_T332191_subdomain_for_new_cloud_private_subnets.


Naming for public exposure of Toolforge tools and other 'native' Toolforge services Replaces deprecated tools.wmflabs.org

  • admin.toolforge.org
  • openstack-browser.toolforge.org

Zone data (records) are stored and served by Designate @ eqiad1. This domains belongs to the tools project and is completely managed in Designate (either horizon or the CLI).

Legacy domains


Within Cloud VPS each instance has a name like <instancename>.<projectname>.eqiad.wmflabs. For historical reasons we also create <instancename>.eqiad.wmflabs DNS entries for each instance. This legacy behavior may be discontinued in the future. Cloud VPS is not just one big flat zone in the same way production is, it is broken into tenants with different access restrictions.

There is a special private domain which is svc.eqiad.wmflabs. which is intended to hold service FQDNs not associated with virtual machines or a specific Cloud VPS project.



Servers involved in this setup.

  • prod DNS servers:
    • service names: ns{0,1,2}.wikimedia.org
    • data managed using operations/dns.git in coordination with the main SRE team.
  • Designate @ eqiad1: running on cloudservices100X.wikimedia.org servers.
    • service names: ns{0,1}.openstack.eqiad1.wikimediacloud.org and ns-recursor{0,1}.openstack.eqiad1.wikimediacloud.org.
    • legacy service names: cloud-ns{0,1}.wikimedia.org and cloud-recursor{0,1}.wikimedia.org
    • data managed using the openstack CLI or Horizon.
  • Designate @ codfw1dev: running on cloudservices200X.dev.wikimedia.org servers.
    • service names: ns{0,1}.openstack.codfw1dev.wikimediacloud.org and ns-recursor{0,1}.openstack.codfw1dev.wikimediacloud.org.
    • old service names: codfw1dev-ns{0,1}.wikimedia.org and codfw1dev-recursor{0,1}.wikimedia.org
    • data managed using the openstack CLI or Horizon.

See also