unioslo/mreg

Ambiguous, implicit PTR

Closed this issue · 4 comments

paalbra commented

The following will lead to an ambiguous, implicit PTR record:

TEST> host add a.example.com -ip 10.0.0.10                                 
OK: : created host a.example.com with IP 10.0.0.10
TEST> host add b.example.com -ip 10.0.0.10 -force                          
OK: : created host b.example.com with IP 10.0.0.10
TEST> host info a.example.com        
Name:         a.example.com
Contact:      
A_Records     IP              MAC
              10.0.0.10       <not set>
PTR override: 10.0.0.10 -> a.example.com
TTL:          (Default)
TEST> host info b.example.com        
Name:         b.example.com
Contact:      
A_Records     IP              MAC
              10.0.0.10       <not set>
TTL:          (Default)
TEST> host ptr_remove 10.0.0.10 a.example.com                              
OK: : deleted PTR record 10.0.0.10 for a.example.com
TEST> host info a.example.com        
Name:         a.example.com
Contact:      
A_Records     IP              MAC
              10.0.0.10       <not set>
TTL:          (Default)
TEST> host info b.example.com        
Name:         b.example.com
Contact:      
A_Records     IP              MAC
              10.0.0.10       <not set>
TTL:          (Default)

Here you will get 10.0.0.10.in-addr.arpa. PTR b.example.com. This seems to be because b.example.com has the highest host id. If you add c.example.com with the same IP the PTR will point to c.example.com.

This is probably not wanted behaviour.

Suggestion:

Don't create an implicit PTR if multiple hosts have the same IP.
OR
Don't allow removal of the explicit PTR override if multiple hosts has the same IP.

oyvindkolbu commented

Here you will get 10.0.0.10.in-addr.arpa. PTR b.example.com.

You should not have gotten any PTR for 10.0.0.10, ref:

mreg/mreg/models.py

Lines 296 to 297 in 59877a9

if ip in multiple_ip_no_ptr:
continue

Can you do a host info 10.0.0.10?

This seems to be because b.example.com has the highest host id.

Again this should not happen.

If you add c.example.com with the same IP the PTR will point to c.example.com.

No, it should not, unless you deleted a.example.com or b.example.com in the meantime.
Ref

mreg/mreg/signals.py

Lines 72 to 73 in 59877a9

qs = Ipaddress.objects.filter(ipaddress=instance.ipaddress)
if qs and qs.count() == 1:
as it would only create an implicit PTR if the ipaddress is used once.

This is probably not wanted behaviour.

Suggestion:

Don't create an implicit PTR if multiple hosts have the same IP.

That should be the current case.

OR
Don't allow removal of the explicit PTR override if multiple hosts has the same IP.

Possible, but not sure if wanted. Could be checked in mreg-cli and request a force argument.

Maybe add an API to get all ipaddresses without a PTR override, but should have one? Aka
ipaddresses not present in a reverse zone.

paalbra commented

Don't create an implicit PTR if multiple hosts have the same IP

... this is probably the best solution (and what it seems like the current code is trying to do).

Looks like the problem is:

This is a dict that stores IP addresses as keys:

mreg/mreg/models.py

Line 266 in 59877a9

ipaddresses = dict()

This loop is looping the keys/IP addresses and the dict will of course never have duplicate keys. Because of this the code will never count duplicates and multiple_ip_no_ptr will be empty:

mreg/mreg/models.py

Lines 279 to 282 in 59877a9

for i in ipaddresses:
if i not in override_ips:
count[i] += 1
multiple_ip_no_ptr = {i: count[i] for i in count if count[i] > 1}

Also: I guess default sort order is the primary key. Therefore you will get a PTR to the newest host/the one with highest pk value.

mbakke commented

This was fixed in #405.