#5466 Make dns-resolve command deprecated.
Closed: Fixed None Opened 8 years ago by mbasti.

This command should not be used, admin should use to find issues with DNS commands 'dig', 'nslookup' or 'host' rather than this command. Command is not safe and it is executed on server side, so it is not helpful with debugging clients.

I suggest to add warning to result of this command, that command is deprecated.

I do not see reason to maintain a copy of 'host' command in IPA.


Where is this coming from? What makes the command "not safe"?

I think that the command being executed on the server was the main point, to let admins ask for DNS resolution, how server sees it. This can help investigating DNS resolution issues.

For example, if you change your /etc/resolv.conf, but you do not restart your httpd server, it still uses the old servers. Without this command, you won't be able to confirm it.

Replying to [comment:1 mkosek]:

Where is this coming from? What makes the command "not safe"?
I would use terms 'unpredictable'/'confusing'/'hard to use' intead of 'safe'.

Let me ilustrate why the command is hard to use:

I think that the command being executed on the server was the main point, to let admins ask for DNS resolution, how server sees it. This can help investigating DNS resolution issues.

... except the fact that ipa command user does not even know which server returned the answer, unless the user is using a debug option. And it will be even worse, read on:

For example, if you change your /etc/resolv.conf, but you do not restart your httpd server, it still uses the old servers. Without this command, you won't be able to confirm it.

There is no relation between point where python-dns reads /etc/resolv.conf and when glibc reads /etc/resolv.conf, so these two libraries might easily work with diffent values inside one Apache process - depending on the point where resolv.conf was changed.

Also, depending on python-magic involved, python-dns might re-read the resolv.conf file at run-time.

I believe that this demostrates that this command does not do what anyone expects and that is the reason why it should be deprecated, burned down, and burried deep.

Replying to [comment:2 pspacek]:
...

I believe that this demostrates that this command does not do what anyone expects and that is the reason why it should be deprecated, burned down, and burried deep.

It does, but what is the counter-proposal then? Can we at least place an advise to FreeIPA Troubleshooting document, how to investigate the scenario I described?

There is no reliable way how to detect problems caused by /etc/resolv.conf change. In theory we could check timestamp on /etc/resolv.conf and scream if it changed after process start, but then we will have problem with schedulign the check etc.

Anyway, the user should restart processes after any change, which is what he has to do anyway because glibc does not re-read the file when the process is running.

Having dns-resolve command does not help because it gives out misleading information, which actually makes debugging harder, not easier.

For better debuggability we need to improve information printed in error messages related to DNS errors, which is covered by #3298 (FreeIPA 4.3.x at the moment).

Seems to me, that we should just improve the command's help so user will know what the command actually does and maybe suggest tools like dig or host for other cases.

master:

  • 749dfc3 Make command dns-resolve deprecated.

Metadata Update from @mbasti:
- Issue assigned to mbasti
- Issue set to the milestone: FreeIPA 4.3

7 years ago

Login to comment on this ticket.

Metadata