Portal:Cloud VPS/Admin/Designate

From Wikitech
Jump to: navigation, search

dns-floating-ip-updater

Labs has a block of public IPs: 208.80.155.128/25

Unfortunately 208.80.155.0/25 are production IPs

Therefore production can't delegate the whole of the 155.80.208.in-addr.arpa. zone to labs NS servers for us to automate reverse DNS records from

Our workaround is RFC 2317-style delegation: We have a zone called 128-25.155.80.208.in-addr.arpa. (living under the wmflabsdotorg tenant IIRC) that production CNAMEs all the usual in-addr records for labs into, and delegates the zone to labs nameservers.

We have a script called dns-floating-ip-updater that sets up instance-{instancename}.{project}.wmflabs.org records (assuming {project}.wmflabs.org exists as a domain, if not they don't get the feature) and the reverse DNS record for that, then also sets up the reverse DNS for all manually curated A records.

What happens when someone makes a reverse DNS lookup, for let's say 208.80.155.131:

  • It gets turned into a PTR lookup on 131.155.80.208.in-addr.arpa. as normal
  • Prod NS servers control the 155.80.208.in-addr.arpa. zone - if you open the file for that in the operations/dns.git repository ('templates' directory), you'll see the first 128 addresses are reserved for prod (some in use, some not)
  • So under 208.80.155, number 131 is IN CNAME 131.128-25 i.e. 131.128-25.155.80.208.in-addr.arpa.
  • 128-25.155.80.208.in-addr.arpa. is delegated from prod to labs NS, i.e. designate.
  • So the full lookup becomes 131.128-25.155.80.208.in-addr.arpa. and is sent to the labs NS server
  • This script ensures that designate knows how to answer that query, by populating all the records.

For example:

$ host bastion.wmflabs.org
bastion.wmflabs.org has address 208.80.155.129 # this is answered by the labs nameservers (designate) as they control wmflabs.org, under the wmflabsdotorg tenant
$ host 208.80.155.129
129.155.80.208.in-addr.arpa is an alias for 129.128-25.155.80.208.in-addr.arpa. # this is the production nameservers delegating the query to labs designate
129.128-25.155.80.208.in-addr.arpa domain name pointer bastion.wmflabs.org. # this is from the labs nameservers (designate) and is because bastion.wmflabs.org points to that IP
129.128-25.155.80.208.in-addr.arpa domain name pointer instance-bastion-01.bastion.wmflabs.org. # this comes from the labs nameservers (designate) and is used to indicate which instance a given IP points to, partially in case it lacks other names, but it's helpful regardless. (think what happens if we didn't have this entry but you wanted to go look up the instance on the project's instance list knowing only it's IP - and that's assuming you know which project to look under)
129.128-25.155.80.208.in-addr.arpa domain name pointer primary.bastion.wmflabs.org. # this is from the labs nameservers (designate) and is because primary.bastion.wmflabs.org points to that IP
$ host instance-bastion-01.bastion.wmflabs.org
instance-bastion-01.bastion.wmflabs.org has address 208.80.155.129 # this comes from the labs nameservers (designate) - wouldn't make sense to provide the PTR above without this

We will need to do some work on our script to be able to add new domains or public IP ranges (e.g. for other datacentres, to introduce IPv6, or to simply get more addresses).

Announcement post: https://www.mail-archive.com/labs-l@lists.wikimedia.org/msg04516.html