currently, when creating/deleting PTR's Foreman converts IP's to PTR
records [1] (hopefully the right place) it seems before sending them off
as attributes to smart-proxy. Turns out, all the tests in smart-proxy
are not honoring this fact. [2]
Can somebody explain to me the reasoning behind this?
I am asking of course because I question it as it leads to issues
downstream with smart-proxy, as I am currently experiencing them [3]:
I think the provider / smart-proxy should be checking for duplicates
as foreman might use other / unreachable name resolution. Nevertheless,
the implemented providers do so already
Reverse DNS find, which we use to search for duplicates, only works
with IP addresses AFAIK
There is no reliable way I know of to to convert a PTR record back to
an IP address. While this might be done with some questionable
.split('.').reverse with IPv4, this gets much more complicated with IPv6
We should remove complexion from Foreman, always send the IP to
smart-proxy and let the provider figure out what method would be best to
set it.
This is a breaking API change; though I think PTRs are currently noop
anyway the way smart-proxy is implementing them.
> Hello dev team,
>
> currently, when creating/deleting PTR's Foreman converts IP's to PTR
> records [1] (hopefully the right place) it seems before sending them off
> as attributes to smart-proxy. Turns out, all the tests in smart-proxy
> are not honoring this fact. [2]
>
> Can somebody explain to me the reasoning behind this?
>
> I am asking of course because I question it as it leads to issues
> downstream with smart-proxy, as I am currently experiencing them [3]:
>
> - I think the provider / smart-proxy should be checking for duplicates
> as foreman might use other / unreachable name resolution. Nevertheless,
> the implemented providers do so already
For MS Dns this makes sense for create PTR operations only, deletes
will always succeed, whether record exists or not.
> - Reverse DNS find, which we use to search for duplicates, only works
> with IP addresses AFAIK
> - There is no reliable way I know of to to convert a PTR record back to
> an IP address. While this might be done with some questionable
> .split('.').reverse with IPv4, this gets much more complicated with IPv6
See above.
>
>
> We should remove complexion from Foreman, always send the IP to
> smart-proxy and let the provider figure out what method would be best to
> set it.
> This is a breaking API change; though I think PTRs are currently noop
> anyway the way smart-proxy is implementing them.
I think it’s highly unlikely that a breaking change such as the one
you are suggesting will be implemented, esp. considering there’s a way
to make provider work without changing the api. That aside, versioning
of api has to happen before such a change can be safely implemented.
Cheers,
-d
···
On Mon, Feb 22, 2016 at 11:50 AM, Daniel Helgenberger wrote:
> Hello dev team,
>
> currently, when creating/deleting PTR's Foreman converts IP's to PTR
> records [1] (hopefully the right place) it seems before sending them off
> as attributes to smart-proxy. Turns out, all the tests in smart-proxy
> are not honoring this fact. [2]
>
> Can somebody explain to me the reasoning behind this?
It is a bug in our tests. I have a commit[4] in PR 371[5] that fixes
this. I'll create a separate PR for this.
> I am asking of course because I question it as it leads to issues
> downstream with smart-proxy, as I am currently experiencing them [3]:
>
> - I think the provider / smart-proxy should be checking for duplicates
> as foreman might use other / unreachable name resolution. Nevertheless,
> the implemented providers do so already
> - Reverse DNS find, which we use to search for duplicates, only works
> with IP addresses AFAIK
> - There is no reliable way I know of to to convert a PTR record back to
> an IP address. While this might be done with some questionable
> .split('.').reverse with IPv4, this gets much more complicated with IPv6
It's trivial to convert a PTR record to an IP, both for IPv4 and IPv6.
> We should remove complexion from Foreman, always send the IP to
> smart-proxy and let the provider figure out what method would be best to
> set it.
> This is a breaking API change; though I think PTRs are currently noop
> anyway the way smart-proxy is implementing them.
I'm pretty sure it currently works. You can use my integration test[6]
to verify it. You only need to modify it to point to the correct
nameserver, smart-proxy and remove the purge_cache (or adapt it to your
backend if it needs it).
I can expand on this if you like or maybe poke me on IRC (ewoud) to
debug together.
I don't think we need to change the Foreman <-> Proxy API for this.
Besides that, we created a consistent internal API with create_record
and remove_record. The only inconsistent thing there is
remove_ptr_record is passed a parameter named ip while it's the reverse
IP notation.
···
On Mon, Feb 22, 2016 at 12:03:08PM +0000, Dmitri Dolguikh wrote:
> On Mon, Feb 22, 2016 at 11:50 AM, Daniel Helgenberger > wrote:
> > We should remove complexion from Foreman, always send the IP to
> > smart-proxy and let the provider figure out what method would be best to
> > set it.
> > This is a breaking API change; though I think PTRs are currently noop
> > anyway the way smart-proxy is implementing them.
>
> I think it’s highly unlikely that a breaking change such as the one
> you are suggesting will be implemented, esp. considering there’s a way
> to make provider work without changing the api. That aside, versioning
> of api has to happen before such a change can be safely implemented.