Page MenuHomePhabricator

Delegate public IP range for Eqiad1-r OpenStack deployment to designate (neutron)
Closed, ResolvedPublic


DNS for our nova-network public range is delegated to the nameservers managed by designate:


; Eqiad Labs virtualization subnet
; Delegate - to labs-ns*

128-25 IN NS
       IN NS

We need to do the same for the range assigned in T193496 i.e.

Event Timeline

chasemp created this task.
chasemp updated the task description. (Show Details)
chasemp updated the task description. (Show Details)

So someone with novaadmin will need to create a designate zone in the wmflabsdotorg project.
Then we'll need to do some refactoring around the floating IP DNS update scripting to make it work on a second zone that doesn't need RFC 2317 trickery

Change 445303 had a related patch set uploaded (by Andrew Bogott; owner: Andrew Bogott):
[operations/dns@master] Delegate to labs-ns0/ns1

Change 445310 had a related patch set uploaded (by Alex Monk; owner: Alex Monk):
[operations/puppet@production] openstack eqiad1: Run dns_floating_ip_updater

Change 445310 merged by Andrew Bogott:
[operations/puppet@production] openstack eqiad1: Run dns_floating_ip_updater

I merged and the entries created look right to me. I can't actually dig -x yet though, presumable because we still need the delegation patch.

Change 445303 merged by Andrew Bogott:
[operations/dns@master] Delegate to labs-ns0/ns1

I merged and the entries created look right to me. I can't actually dig -x yet though, presumable because we still need the delegation patch.

As long as you point it at the right DNS server you should be fine regardless of delegations, but:

alex@alex-laptop:~$ dig +short
alex@alex-laptop:~$ dig -x +short

looking at horizon, the wmflabsdotorg project's zone clearly has a PTR record with the value (so my script appears to be working) - but when I query labs-ns0 or labs-ns1 for it, the record is nowhere to be seen?

alex@alex-laptop:~$ dig PTR

; <<>> DiG 9.11.3-1ubuntu1.1-Ubuntu <<>> PTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42930
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

; EDNS: version: 0, flags:; udp: 2800

;; Query time: 162 msec
;; WHEN: Fri Aug 31 23:15:51 BST 2018
;; MSG SIZE  rcvd: 54

image.png (283×1 px, 29 KB)

labs-ns* responses look fine now though. @Andrew might this be to do with the eqiad <-> eqiad1-r designate change you made today?

There is a problem with the delegation though, prod isn't returning the NS record into labs where I'd expect, instead we get the SOA?

alex@alex-laptop:~$ dig PTR +trace @

[snip]	172800	IN	NS	172800	IN	NS	172800	IN	NS	3600	IN	NSEC NS RRSIG NSEC	3600	IN	RRSIG	NSEC 8 5 3600 20181002134304 20180902124304 64230 cPGxkgvEanbIEsvtoALMTjLa6gqB/QluqS6e/glE+k0zE29reh9S8fxC MKW2EpeDDsWgMtMqRcAqslQBl2ZmcJLleMqlYM2NPioeLGivNKQCtxxD m3ZHFoZPnp+J6HMLuDczMihrQm6/mkvoaGZJNzbj370srhXjlvAD3Qxj ims=
;; Received 369 bytes from in 82 ms	3600	IN	SOA 2018083120 43200 7200 1209600 3600
;; Received 123 bytes from in 173 ms
alex@alex-laptop:~$ dig PTR +short

So I wonder if that operations/dns.git commit is correct. It might be easier if we just have them point reverse DNS queries straight at the labs nameservers instead of going via prod gdnsd. That wasn't possible on the old setup as our range was a /25 (, and the other /25 within that /24 ( was prod stuff, but we can do it here as the entire /24 ( is reserved for labs.

After and fixing a silly typo, I now think that the ptr records should be updating correctly and promptly.

I don't really know what the NS record should look like... maybe @BBlack has thoughts?

I wonder if gdnsd doesn't like the NS record out to another server at the zone apex like that. Could create an NS record for each of 0-255 I guess.

I spoke with Brandon Black in -traffic just now, basically you can't delegate a full zone like this (nor in several other ways I suggested) - and changing RIPE to point directly at labs-ns* might be complicated by the fact that WMF owns the larger /22 rather than just this /24
(edit: he wrote the best way, if supported by RIPE, would be to ask RIPE to change the delegation, but only for this 1x /24 (which is part of a contiguous /22 they gave us, so I'm not sure of that's possible))
Here's what we can do, to set up in a similar way to the old (I had been thinking we could avoid this but apparently not):

  1. create zone in designate
  2. change hieradata/eqiad/profile/openstack/eqiad1/designate.yaml: profile::openstack::eqiad1::designate::floating_ip_ptr_fqdn_replacement_pattern: '\'
  3. let it run
  4. change templates/ to be like (edit: Also Brandon said maybe bump up the delegation + CNAME record TTLs all to 1D)
  5. test it all is working
  6. delete old zone from designate

(designate zones should/can be found under the wmflabsdotorg tenant)

I just edited the object in the RIPE database to point nameservers directly to labs-ns0/1. This should work now, no need for classful classless delegation :)

Change 462574 had a related patch set uploaded (by Faidon Liambotis; owner: Faidon Liambotis):
[operations/dns@master] Remove, moved to labs-ns0/1

Thanks @faidon

alex@alex-laptop:~$ host has address
alex@alex-laptop:~$ host domain name pointer
alex@alex-laptop:~$ host has address
alex@alex-laptop:~$ host domain name pointer

Change 462574 merged by Faidon Liambotis:
[operations/dns@master] Remove, moved to labs-ns0/1

Note that there is the RIPE's TTL at play here, which is set to 172800 (2 days), so I'd wait for that before I start using these records.