Page MenuHomePhabricator

eqiad1 private IPs lacking PTRs in DNS
Closed, ResolvedPublic

Description

Per @aborrero's comments on IRC about T202886: cloudvps: eqiad1: create DNS PTR records for cloud addresses, I just SSH'd to eqiad1.bastion.wmflabs.org and confirmed that something is wrong here:

krenair@bastion-eqiad1-01:~$ ip addr | grep 172
    inet 172.16.1.136/21 brd 172.16.7.255 scope global eth0
krenair@bastion-eqiad1-01:~$ host 172.16.1.136
Host 136.1.16.172.in-addr.arpa. not found: 3(NXDOMAIN)
krenair@bastion-eqiad1-01:~$ dig 136.1.16.172.in-addr.arpa. PTR

; <<>> DiG 9.10.3-P4-Debian <<>> 136.1.16.172.in-addr.arpa. PTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9148
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;136.1.16.172.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
16.172.in-addr.arpa.	718	IN	SOA	localhost. root. 1 604800 86400 2419200 604800

;; Query time: 0 msec
;; SERVER: 208.80.155.118#53(208.80.155.118)
;; WHEN: Tue Aug 28 22:19:43 UTC 2018
;; MSG SIZE  rcvd: 92

krenair@bastion-eqiad1-01:~$ dig 136.1.16.172.in-addr.arpa. PTR @labs-ns0.wikimedia.org

; <<>> DiG 9.10.3-P4-Debian <<>> 136.1.16.172.in-addr.arpa. PTR @labs-ns0.wikimedia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40775
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

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

;; Query time: 2 msec
;; SERVER: 208.80.155.117#53(208.80.155.117)
;; WHEN: Tue Aug 28 22:19:53 UTC 2018
;; MSG SIZE  rcvd: 54

Somewhere in Designate I recall there being a special zone like 10.in-addr.arpa. (may have required some special rights/headers to get to that, maybe sudo to a special tenant which I've forgotten the name of) that nova managed PTR records under, there should be something similar for 172.in-addr.arpa.

Event Timeline

Krenair triaged this task as Medium priority.Aug 28 2018, 10:22 PM
Krenair raised the priority of this task from Medium to Needs Triage.
Krenair created this task.

Wouldn't be surprised actually if everything around the nova_fixed_multi stuff needs to be rethought. I have noticed in ./modules/openstack/templates/mitaka/designate/designate.conf.erb there is some commented out neutron settings, I wonder what it does.

Wouldn't be surprised actually if everything around the nova_fixed_multi stuff needs to be rethought. I have noticed in ./modules/openstack/templates/mitaka/designate/designate.conf.erb there is some commented out neutron settings, I wonder what it does.

Neutron has a new integration mechanism that's meant to replace sink -- it can actively call out to Designate for record creation rather than relying on async and unreliable notifications.

That's definitely the way forward, but it's also totally broken in Mitaka. So, sink lives on until at least one version upgrade.

Remembered the name of the special project which may house 10.in-addr.arpa. - I think it was noauth-project, and there's a few hits for that in the designate source

Krenair assigned this task to Andrew.

Looks like this got fixed