Bizarre behaviour of DNS and hosts file - Mandriva

This is a discussion on Bizarre behaviour of DNS and hosts file - Mandriva ; I am having weird problems. Here is the output of a command. Subject: Cron for i in `cat /usr/local/adm/computers/rhosts`; do\ scp $i:computers/noping /tmp/noping; scp /tmp/noping \ monopole:/local/http/htdocs/noping.$i; done ssh: dilaton: Name or service not known Now, dilaton is the second ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Bizarre behaviour of DNS and hosts file

  1. Bizarre behaviour of DNS and hosts file

    I am having weird problems. Here is the output of a command.

    Subject: Cron for i in `cat /usr/local/adm/computers/rhosts`; do\
    scp $i:computers/noping /tmp/noping; scp /tmp/noping \
    monopole:/local/http/htdocs/noping.$i; done

    ssh: dilaton: Name or service not known

    Now, dilaton is the second computer listed in
    /usr/local/adm/computers/rhosts
    and it is listed in the /etc/hosts file (as are the other 7 computers
    listed in that file) I only get this error sporadically ( about once a day
    when the cron runs that command every 15 min)
    I also get something similar in which suddenly another of the machine will
    not be recognised on a similar command but using ping, not ssh.

    Ie, every once in a while the system will claim it cannot find a computer,
    which is listed in /etc/hosts.
    What in the world could cause this kind of bizarre behaviour

    (Note-- that script is run by root from the crontab.
    )


  2. Re: Bizarre behaviour of DNS and hosts file

    On Wed, 16 Jan 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Bill Unruh wrote:

    >I am having weird problems.


    There are other kinds??? ;-)

    >ssh: dilaton: Name or service not known
    >
    >Now, dilaton is the second computer listed in
    >/usr/local/adm/computers/rhosts
    >and it is listed in the /etc/hosts file (as are the other 7 computers
    >listed in that file) I only get this error sporadically ( about once


    Random failures are symptomatic of DNS, rather than the hosts file
    (which I hope isn't changing that frequently - did you look at the
    file date/time?). Verify the contents of /etc/nsswitch.conf makes
    sense for your name resolution,

    [compton ~]$ grep host /etc/nsswitch.conf
    hosts: files nis dns
    [compton ~]$

    here, /etc/hosts first, then NIS, then DNS. With 'files' first,
    it shouldn't be looking for NIS or DNS, so then verify /etc/resolv.conf
    looking at 'domain' and/or 'search directives (I don't like using
    either, but make sure you have ONLY ONE not both, and make sure the
    extra crap they may add is coherent). COMMENT: It looks as if you
    are not calling hosts by their FQDN - that _can_ be a security risk.

    I'd then run your favorite packet sniffer, looking for DNS (or NIS as
    appropriate) traffic. For tcpdump and DNS, try

    /usr/sbin/tcpdump -ni eth0 -s 512 port 53

    (Not specifying UDP, to allow for TCP queries for long answers.) Look
    at the questions being asked (what hostname is it looking for), and the
    answers received. Also, are ALL nameservers in /etc/resolv.conf set
    with identical zone files? Recall that the resolver believes the first
    answer it receives - so if one name server doesn't know the answer,
    you'll get an NXDOMAIN, and the game is over. Finally, unless you've
    mucked with the header files (/usr/include/resolv.h) it's three name
    servers maximum.

    >Ie, every once in a while the system will claim it cannot find a computer,
    >which is listed in /etc/hosts.
    >What in the world could cause this kind of bizarre behaviour


    Are the hosts _also_ in DNS or NIS? The normal reason I've seen is as
    above - /etc/nsswitch.conf (/etc/host.conf for old applications) not
    looking at the host file, and search/domain directives in /etc/resolv.conf
    causing weird names to be looked up. That's why I prefer to use the FQDN
    (complete with trailing dot).

    Old guy

  3. Re: Bizarre behaviour of DNS and hosts file

    ibuprofin@painkiller.example.tld (Moe Trin) writes:

    >On Wed, 16 Jan 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    >, Bill Unruh wrote:


    >>I am having weird problems.


    >There are other kinds??? ;-)


    >>ssh: dilaton: Name or service not known
    >>
    >>Now, dilaton is the second computer listed in
    >>/usr/local/adm/computers/rhosts
    >>and it is listed in the /etc/hosts file (as are the other 7 computers
    >>listed in that file) I only get this error sporadically ( about once


    >Random failures are symptomatic of DNS, rather than the hosts file
    >(which I hope isn't changing that frequently - did you look at the
    >file date/time?). Verify the contents of /etc/nsswitch.conf makes
    >sense for your name resolution,


    >[compton ~]$ grep host /etc/nsswitch.conf
    >hosts: files nis dns
    >[compton ~]$


    hosts: files nisplus nis dns


    ( That is default. I do not use eitehr nis or nisplus. I suppose I could
    try removing those. Except all of those hosts are in the /etc/hosts files,
    where they are usually found.
    )


    >here, /etc/hosts first, then NIS, then DNS. With 'files' first,
    >it shouldn't be looking for NIS or DNS, so then verify /etc/resolv.conf
    >looking at 'domain' and/or 'search directives (I don't like using
    >either, but make sure you have ONLY ONE not both, and make sure the
    >extra crap they may add is coherent). COMMENT: It looks as if you
    >are not calling hosts by their FQDN - that _can_ be a security risk.


    I suppose so. but all of those hosts are in the /etc/hosts file, so it
    should NOT be going out onto the net.



    >I'd then run your favorite packet sniffer, looking for DNS (or NIS as
    >appropriate) traffic. For tcpdump and DNS, try


    > /usr/sbin/tcpdump -ni eth0 -s 512 port 53


    That is an idea. Thanks.



    >(Not specifying UDP, to allow for TCP queries for long answers.) Look
    >at the questions being asked (what hostname is it looking for), and the
    >answers received. Also, are ALL nameservers in /etc/resolv.conf set
    >with identical zone files? Recall that the resolver believes the first
    >answer it receives - so if one name server doesn't know the answer,
    >you'll get an NXDOMAIN, and the game is over. Finally, unless you've
    >mucked with the header files (/usr/include/resolv.h) it's three name
    >servers maximum.


    >>Ie, every once in a while the system will claim it cannot find a computer,
    >>which is listed in /etc/hosts.
    >>What in the world could cause this kind of bizarre behaviour


    >Are the hosts _also_ in DNS or NIS? The normal reason I've seen is as
    >above - /etc/nsswitch.conf (/etc/host.conf for old applications) not
    >looking at the host file, and search/domain directives in /etc/resolv.conf


    It is set up for hosts file. I would seem that for some reason occasionally
    it does not look there.

    >causing weird names to be looked up. That's why I prefer to use the FQDN
    >(complete with trailing dot).


    > Old guy


  4. Re: Bizarre behaviour of DNS and hosts file

    On Thu, 17 Jan 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , Unruh wrote:

    >ibuprofin@painkiller.example.tld (Moe Trin) writes:


    >>Random failures are symptomatic of DNS, rather than the hosts file
    >>(which I hope isn't changing that frequently - did you look at the
    >>file date/time?)


    Did you have time to check that?

    >hosts: files nisplus nis dns
    >
    >( That is default. I do not use eitehr nis or nisplus. I suppose I
    >could try removing those. Except all of those hosts are in the
    >/etc/hosts files, where they are usually found.
    >)


    I'm not sure that the nis/nisplus would make a difference, which is
    why it's included as a default. Worst case, it adds some CPU cycles
    while the resolver looks to see if the yptools are even installed
    (never mind configured).

    On the other hand - computers are supposed to follow instructions
    exactly. So, any time an application wants to resolve a name, it should
    follow the same steps, and find the same answer. If it _is_ trying
    to resolve an exact name found in the /etc/hosts file, it should always
    find it - no random failures. The fact that you are seeing such random
    failures can mean only a few things - either the /etc/hosts file is
    changing, or becoming non-visible for some reason, or the name that the
    resolver is trying to look up is not what you think it is, and is not
    the same as the name in the hosts file. It says here you could always
    try to 'strace' the application to see that it is actually doing what
    you expected.

    >> COMMENT: It looks as if you are not calling hosts by their FQDN - that
    >> _can_ be a security risk.

    >
    >I suppose so. but all of those hosts are in the /etc/hosts file, so it
    >should NOT be going out onto the net.


    Are they in there with both the FQDN and any alias which would include
    the short name ('theory.physics.ubc.ca' verses 'theory')? If your
    script is calling for the short name, it will only look for the short
    name in the hosts file - the 'search' and 'domain' directives in the
    /etc/resolv.conf file only effect nameserver lookups, not _all_
    lookups. If it doesn't find the short name it's looking for, it will
    then try the DNS, and that can then invoke the 'search' or 'domain'
    directives. Then, the random failures could occur if ALL of the
    nameservers don't have exactly the same zonefiles.

    >It is set up for hosts file. I would seem that for some reason
    >occasionally it does not look there.


    That doesn't make sense. With the /etc/nsswitch.conf shown, it WILL
    look in the hosts file (assuming the application is doing the normal
    gethostbyname() call), and the question then becomes 1) is it looking
    for an exact name that is found in that file (think 'grep -w' as
    opposed to 'grep' alone), and 2) is the file accessible when the
    resolver is trying to look up the name.

    Old guy

  5. Re: Bizarre behaviour of DNS and hosts file

    ibuprofin@painkiller.example.tld (Moe Trin) writes:

    >On Thu, 17 Jan 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    >, Unruh wrote:


    >>ibuprofin@painkiller.example.tld (Moe Trin) writes:


    >>>Random failures are symptomatic of DNS, rather than the hosts file
    >>>(which I hope isn't changing that frequently - did you look at the
    >>>file date/time?)


    >Did you have time to check that?


    I has not changed in 4 months.


    >>hosts: files nisplus nis dns
    >>
    >>( That is default. I do not use eitehr nis or nisplus. I suppose I
    >>could try removing those. Except all of those hosts are in the
    >>/etc/hosts files, where they are usually found.
    >>)


    >I'm not sure that the nis/nisplus would make a difference, which is
    >why it's included as a default. Worst case, it adds some CPU cycles
    >while the resolver looks to see if the yptools are even installed
    >(never mind configured).


    >On the other hand - computers are supposed to follow instructions
    >exactly. So, any time an application wants to resolve a name, it should
    >follow the same steps, and find the same answer. If it _is_ trying
    >to resolve an exact name found in the /etc/hosts file, it should always
    >find it - no random failures. The fact that you are seeing such random
    >failures can mean only a few things - either the /etc/hosts file is
    >changing, or becoming non-visible for some reason, or the name that the
    >resolver is trying to look up is not what you think it is, and is not
    >the same as the name in the hosts file. It says here you could always
    >try to 'strace' the application to see that it is actually doing what
    >you expected.


    The application is either ping or ssh. Both are pretty standard.



    >>> COMMENT: It looks as if you are not calling hosts by their FQDN - that
    >>> _can_ be a security risk.

    >>
    >>I suppose so. but all of those hosts are in the /etc/hosts file, so it
    >>should NOT be going out onto the net.


    >Are they in there with both the FQDN and any alias which would include
    >the short name ('theory.physics.ubc.ca' verses 'theory')? If your


    Yes, it is both. And as I said, it usually (90%) works. It is just that
    once per day that is puzzling.


    >script is calling for the short name, it will only look for the short
    >name in the hosts file - the 'search' and 'domain' directives in the
    >/etc/resolv.conf file only effect nameserver lookups, not _all_
    >lookups. If it doesn't find the short name it's looking for, it will
    >then try the DNS, and that can then invoke the 'search' or 'domain'
    >directives. Then, the random failures could occur if ALL of the
    >nameservers don't have exactly the same zonefiles.


    >>It is set up for hosts file. I would seem that for some reason
    >>occasionally it does not look there.


    >That doesn't make sense. With the /etc/nsswitch.conf shown, it WILL
    >look in the hosts file (assuming the application is doing the normal
    >gethostbyname() call), and the question then becomes 1) is it looking
    >for an exact name that is found in that file (think 'grep -w' as
    >opposed to 'grep' alone), and 2) is the file accessible when the
    >resolver is trying to look up the name.


    That is why I called it bizarre. It should look in hosts always. but
    sometimes it seems it does not. And yes it is weird.



    > Old guy


+ Reply to Thread