in reply to Re: Reliable FQDN from IP
in thread Reliable FQDN from IP

I'd already looked into using the following which I think I'm right in saying is fundamentally the same as your code snippet suggestion (unless of course yours forces BIND in which case perfect!):
$hostname = gethostbyaddr( inet_aton($ip), AF_INET );

[download]
But unfortunately gethostbyaddr by design searches the sources listed in /etc/nsswitch.conf or similar.

For me this is undesirable as my single source of truth for the FQDN is not the client but DNS. With /etc/nsswitch.conf set to local followed by bind the query is likely to resolve from /etc/hosts first which cannot be relied upon to be accurate.

Replies are listed 'Best First'.
Re^3: Reliable FQDN from IP
by afoken (Chancellor) on Nov 09, 2012 at 05:58 UTC
    With /etc/nsswitch.conf set to local followed by bind the query is likely to resolve from /etc/hosts first which cannot be relied upon to be accurate.

    Theoretically correct. But have a look at your /etc/hosts: In any environment with a working DNS setup, you should find no other record than localhost 127.0.0.1 and perhaps localhost ::1. So, for any other IP address, DNS is queried. If you fear that someone manipulates /etc/hosts, you fear that someone gains root privileges on that machine. Why do you run code on a machine you can not trust?

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]
      Why do you run code on a machine you can not trust?

      Why do you write code that can run correctly on a machine that you cannot trust? Clearly, nobody should ever write code that might be run on a machine where somebody else has root access. :)

      - tye        

[reply]
      Not true I'm afraid. At a minimum most machines will have their primary interface and the hostname of its other interfaces within /etc/hosts.

      Whilst you shouldn't underestimate the benefit of considering things that shouldn't happen in your environment, ie. access to root, that is not the reason for wanting to ensure we solely query DNS in this instance. DNS is my single source of truth and I do not wish to work with assumptions in order for my code to work.

      Additionally it'll run across 100K+ hosts therefore you have to work with the lowest common denominator to ensure your code is portable across that number of hosts.

      Hence why:

      Perl 5.8.8
      Core modules
      and force DNS lookup.

      This isn't really a Perl discussion now though.
[reply]
        DNS is my single source of truth and I do not wish to work with assumptions in order for my code to work.

        How can you be sure that DNS requests send / DNS responses received by your script or an underlying library are not manipulated?

        Perl 5.8.8
        Core modules
        and force DNS lookup.

        It seems the core modules of 5.8.8 are not sufficient to solve your problem, because there seems to be no interface to configure the DNS resolving functions. So you need to include code to resolve from Perl. Net::DNS can do that. It contains some XS code, but using XS is optional. The same is true for some Win32 specific dependancies. Read the Makefile.PL in Net::DNS for details. Include Net::DNS in your code, and you have complete control over name resolution.

        This isn't really a Perl discussion now though.

        Who cares? I still do not understand why you think that you need to resolve only using the DNS. What is your actual problem you want so solve?

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]

In Section Seekers of Perl Wisdom