Bug #1558
closed
Smart Proxy for DNS PTR is not chosen properly
Description
The Smart Proxy that is used for updating the DNS PTR entries is - afaict - the same that is used for the forward record.
However, the Smart-Proxy to be used should be chosen based on the subnet and not based on the domain.
Updated by Ohad Levy about 13 years ago
- Status changed from New to Need more information
can you please provide more details/examples?
Updated by Andreas Rogge about 13 years ago
Example:
I got two DNS smart proxies foo and bar.
foo handles the zones foo.example.com and 2.0.192.in-addr.arpa.
bar handles the zones bar.example.com and 100.51.198.in-addr.arpa.
Now I create three hosts:
huey - domain foo.example.com, subnet 192.0.2.0
dewey - domain bar.example.com, subnet 198.51.100.0
louie - domain foo.example.com, subnet 198.51.100.0
As far as I can tell the current behaviour would lead to the following situation:
For huey both DNS entries will be created via smart-proxy foo
For dewey both DNS entries will be created via smart-proxy bar
For louie both DNS entries will be created via smart-proxy foo
The last one - louie - will fail, as is isn't possible to add a PTR for subnet 198.51.100.0 in zone 100.51.198.in-addr.arpa through smart-proxy foo.
Foreman should decide which smart-proxy to use for adding the reverse DNS record based on the configuration of the subnet.
Additionally Foreman should skip the reverse DNS record when no dns smart-proxy is configured for the subnet as this means there is no way for foreman to manage the PTR record.
Updated by Ohad Levy almost 13 years ago
- Category set to DNS
- Status changed from Need more information to New
- Assignee set to Ohad Levy
- Target version set to 1.0
Updated by Ohad Levy almost 13 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset commit:"dc8c54dfd229b5a1dbcd5276f6f849310c4c59d7".