cloudvps: eqiad1: create DNS PTR records for cloud addresses
Open, NormalPublic

Description

In T202750 @ayounsi mentioned we should create the PTR records for cloud addresses.

By now I will only think on eqiad1 which is the new deployment, to try to do things right from the beginning.

  • 185.15.56.0/25 - floating IPs
  • 10.64.22.0/24 - labs-instance-transport1-b-eqiad
  • 172.16.0.0/21 - labs-instances2-b-eqiad

Any suggestions for the naming scheme of these static FQDNs?

Some ideas:

  • 185.15.56.1 - cloud-floating-eqiad1-185-15-56-1.wikimedia.org
  • 10.64.22.1 - cloud-instance-transport1-b-10-64-22-1.eqiad.wmnet
  • 172.16.0.1 - cloud-instances2-b-172-16-0-1.eqiad.wmnet
aborrero triaged this task as Normal priority.

The floating IPs will get managed dynamically on the labs nameservers, the PTR should always include the actual instance name and project, not just a useless copy of the IP.

The floating IPs will get managed dynamically on the labs nameservers, the PTR should always include the actual instance name and project, not just a useless copy of the IP.

Ok, @ayounsi does this sounds good?

I'm not the authority in term of naming.

That said, it sounds like a great idea.

The floating IPs will get managed dynamically on the labs nameservers, the PTR should always include the actual instance name and project, not just a useless copy of the IP.

Other vlans should have the name of the host as well (even more so when the hosts are static), plus the interface if not the primary one (eg. eth1-2120.labtestneutron2001.codfw.wmnet. or vl2001-eth1.lvs2004.codfw.wmnet.)

Krenair added a comment.EditedAug 27 2018, 5:31 PM

So we chatted about this on -cloud-admin and here's roughly what me, @Andrew and @aborrero have come up with

  1. subnet-name-ip-addr.somedomain names aren't particularly helpful
  2. floating address names should be managed dynamically as they are in the current deployment, with https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/445310/ and https://gerrit.wikimedia.org/r/#/c/operations/dns/+/445303/
  3. transport address (which likely include a single physical router as well as one or more virtual routers managed by neutron) names *may* be managed statically in operations/dns.git as only cloud admins will be able to create/delete stuff here. it could be done dynamically if someone really wanted or we needed them to be created/removed automatically by scripts, with just a manual addition for the physical core router. The names used here should indicate which router the address is actually for.
  4. the instances subnet's dynamic naming in the new deployment should currently be working. Let's open a separate task if it isn't (might be a missing delegation??)

So:

So, transport IPs, we've already got three physical addresses assigned there to physical routers:

; 10.64.22.0/24 - cloud-instance-transport1-b-eqiad
$ORIGIN 22.64.{{ zonename }}.
1   1H IN PTR   vrrp-gw-1120.eqiad.wmnet.
2   1H IN PTR   ae2-1120.cr1-eqiad.wikimedia.org.
3   1H IN PTR   ae2-1120.cr2-eqiad.wikimedia.org.

I guess someone with access to the admin project (novaobserver doesn't have it) needs to go through, find all the virtual routers attached to it, name them, and stick the results in operations/dns.git

Change 460320 had a related patch set uploaded (by Arturo Borrero Gonzalez; owner: Arturo Borrero Gonzalez):
[operations/dns@master] cloudvps: eqiad1: add cloudinstances2b virtual router FQDNs

https://gerrit.wikimedia.org/r/460320

Change 461024 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] wmcs pdns-recursor: comma-delimit reverse lookup zones

https://gerrit.wikimedia.org/r/461024

Change 461024 merged by Andrew Bogott:
[operations/puppet@production] wmcs pdns-recursor: comma-delimit reverse lookup zones

https://gerrit.wikimedia.org/r/461024

The above patch fixes PTRs for internal and floating eqiad1 addresses. Floating IPs still need work:

andrew@eqiad1test:~$ dig +short -x 172.16.1.177
eqiad1test.testlabs.eqiad.wmflabs.
andrew@eqiad1test:~$ dig +short @labs-recursor0.wikimedia.org -x 172.16.1.177
eqiad1test.testlabs.eqiad.wmflabs.
andrew@eqiad1test:~$ dig +short @labs-recursor1.wikimedia.org -x 172.16.1.177
eqiad1test.testlabs.eqiad.wmflabs.
andrew@eqiad1test:~$ dig +short @labs-recursor2.wikimedia.org -x 172.16.1.177
eqiad1test.testlabs.eqiad.wmflabs.
andrew@eqiad1test:~$ dig +short -x 185.15.56.28
andrew@eqiad1test:~$ dig +short @labs-ns0.wikimedia.org -x 185.15.56.28
gerrit.git.wmflabs.org.

Change 461126 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/puppet@production] wmcs pdns: added forwarding for floating IP ptr records

https://gerrit.wikimedia.org/r/461126

Change 461126 merged by Andrew Bogott:
[operations/puppet@production] wmcs pdns: added forwarding for floating IP ptr records

https://gerrit.wikimedia.org/r/461126

floating IPs should work now too.

andrew@util-abogott:~$ dig +short  -x 185.15.56.28
gerrit.git.wmflabs.org.

Not for me:

alex@alex-laptop:~$ dig -x 185.15.56.28

; <<>> DiG 9.11.3-1ubuntu1.2-Ubuntu <<>> -x 185.15.56.28
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 32036
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;28.56.15.185.in-addr.arpa.	IN	PTR

;; Query time: 341 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Sep 24 17:12:21 BST 2018
;; MSG SIZE  rcvd: 54

Ah, you're right -- it works from within the cloud network but the delegation on ns0 must still be wrong.

So floating and fixed IPs are working. Is the transport IP list complete? If so we can mark this done?

Krenair added a comment.EditedMon, Sep 24, 11:38 PM

I just noticed that the 10.68.23.253 IP in T202636#4573567 is not named.
I've also found that 172.16.0.1 is not named.