nslookup(IP address) => hostname, but nslookup(hostname) => NXDOMAIN !?! - TCP-IP

This is a discussion on nslookup(IP address) => hostname, but nslookup(hostname) => NXDOMAIN !?! - TCP-IP ; I need to convince a large ISP that the practice of giving out hostnames that don't resolve back to IP addresses is a bad thing, but I can't find what RFC(s) address the issue. From what I understand, if a ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: nslookup(IP address) => hostname, but nslookup(hostname) => NXDOMAIN !?!

  1. nslookup(IP address) => hostname, but nslookup(hostname) => NXDOMAIN !?!

    I need to convince a large ISP that the practice of giving out hostnames
    that don't resolve back to IP addresses is a bad thing, but I can't find
    what RFC(s) address the issue.

    From what I understand, if a name server returns a hostname for a given
    IP address, the name SHOULD [MUST?] resolve back to that [an] IP address.

    I seem to recall some FTP servers that will reject a connection from a
    host whose name (derived from the IP address) doesn't resolve. A few
    examples of such servers might convice this ISP of the error of their
    ways.

    Patrick
    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==================== What goes around, comes around... =====================

  2. Re: nslookup(IP address) => hostname, but nslookup(hostname) => NXDOMAIN !?!

    In article , patrick@klos.com wrote:

    > I need to convince a large ISP that the practice of giving out hostnames
    > that don't resolve back to IP addresses is a bad thing, but I can't find
    > what RFC(s) address the issue.
    >
    > From what I understand, if a name server returns a hostname for a given
    > IP address, the name SHOULD [MUST?] resolve back to that [an] IP address.
    >
    > I seem to recall some FTP servers that will reject a connection from a
    > host whose name (derived from the IP address) doesn't resolve. A few
    > examples of such servers might convice this ISP of the error of their
    > ways.


    RFC 1035 says: "Both the gateway pointers at network nodes and the
    normal host pointers at full address nodes use the PTR RR to point back
    to the primary domain names of the corresponding hosts."

    RFC 1034 says: "Domain names in RRs which point at another name should
    always point at the primary name and not the alias."

    In addition to what the RFC's say, there's a logical reason to require
    that the hostname in a PTR record resolve. Anyone who controls a
    reverse zone can put any name in a PTR record. The only way to verify
    that the name in the PTR record is valid is to try to resolve the name,
    since that is controlled by the owner of the forward zone. The fact
    that reverse DNS is easily spoofed is the reason why many systems reject
    clients whose reverse DNS fails this check.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***

  3. Re: nslookup(IP address) => hostname, but nslookup(hostname) => NXDOMAIN !?!

    BM> The only way to verify that the name in the PTR record is valid [...]

    You are presuming that there is a notion of "validity". There isn't.



    BM> The fact that reverse DNS is easily spoofed [...]

    You are presuming that some mappings are "spoofs" and some are not.
    This is not the case. An administrator can map an IP address to any
    domain name of his/her choosing, and is the final, and sole, arbiter of
    whether that mapping is valid. The concept of spoofing only enters into
    it when it comes to third party attackers injecting fake responses into
    DNS transactions to try to alter what the address->name mapping is.

    BM> The fact that reverse DNS is easily spoofed is the reason why many
    BM> systems reject clients whose reverse DNS fails this check.

    Wrong. The reason that some systems reject such clients is that their
    administrators or the authors of the softwares wrote their softwares to
    do so, which was in turn because of a recommendation that David Barr put
    in RFC 1912, which was in turn because he observed administrators and
    software authors making this check, which was in turn because he himself
    had spent the previous several years convincing them to make it in the
    first place, on spurious "security" grounds (which have never withstood
    scrutiny). It's a self-fulfilling and entirely circular thing.

  4. Re: nslookup(IP address) => hostname, but nslookup(hostname) => NXDOMAIN !?!

    p> I need to convince a large ISP that the practice of giving out
    p> hostnames that don't resolve back to IP addresses is a bad thing, but
    p> I can't find what RFC(s) address the issue.



  5. Re: nslookup(IP address) => hostname, but nslookup(hostname) => NXDOMAIN !?!

    In article ,
    Jonathan de Boyne Pollard wrote:

    > BM> The only way to verify that the name in the PTR record is valid [...]
    >
    > You are presuming that there is a notion of "validity". There isn't.
    >
    > http://homepages.tesco.net./~J.deBoy...-double-revers
    > e.html>
    >
    > BM> The fact that reverse DNS is easily spoofed [...]
    >
    > You are presuming that some mappings are "spoofs" and some are not.
    > This is not the case. An administrator can map an IP address to any
    > domain name of his/her choosing, and is the final, and sole, arbiter of
    > whether that mapping is valid. The concept of spoofing only enters into
    > it when it comes to third party attackers injecting fake responses into
    > DNS transactions to try to alter what the address->name mapping is.


    I disagree. There are only a handful of machines that can correctly lay
    claim to being (say) a.b.com. But anyone who manages a reverse zone can
    add PTR records that map to that name, without having to do anything to
    fool the protocol. But the ones that don't correspond to the actual
    machines with this name are clearly wrong. And the only way to
    determine this is to resolve a.b.com and see if it maps to the address
    you started with.

    > BM> The fact that reverse DNS is easily spoofed is the reason why many
    > BM> systems reject clients whose reverse DNS fails this check.
    >
    > Wrong. The reason that some systems reject such clients is that their
    > administrators or the authors of the softwares wrote their softwares to
    > do so, which was in turn because of a recommendation that David Barr put
    > in RFC 1912, which was in turn because he observed administrators and
    > software authors making this check, which was in turn because he himself
    > had spent the previous several years convincing them to make it in the
    > first place, on spurious "security" grounds (which have never withstood
    > scrutiny). It's a self-fulfilling and entirely circular thing.


    If you do any kind of access control by domain name, such as hostnames
    or *. in /etc/hosts.allow or ~/.rhosts, you certainly need to
    verify that the names you get back from reverse lookups are legitimate.
    Otherwise, anyone who manages their reverse DNS could get around these
    checks, since they can make their hostname be anything they want.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***

  6. Re: nslookup(IP address) => hostname, but nslookup(hostname) => NXDOMAIN !?!

    Jonathan de Boyne Pollard wrote:
    > BM> The only way to verify that the name in the PTR record is valid [...]


    > You are presuming that there is a notion of "validity". There isn't.


    >


    > BM> The fact that reverse DNS is easily spoofed [...]


    > You are presuming that some mappings are "spoofs" and some are not.
    > This is not the case. An administrator can map an IP address to any
    > domain name of his/her choosing, and is the final, and sole, arbiter of
    > whether that mapping is valid. The concept of spoofing only enters into
    > it when it comes to third party attackers injecting fake responses into
    > DNS transactions to try to alter what the address->name mapping is.


    > BM> The fact that reverse DNS is easily spoofed is the reason why many
    > BM> systems reject clients whose reverse DNS fails this check.


    > Wrong. The reason that some systems reject such clients is that their
    > administrators or the authors of the softwares wrote their softwares to
    > do so, which was in turn because of a recommendation that David Barr put
    > in RFC 1912, which was in turn because he observed administrators and
    > software authors making this check, which was in turn because he himself
    > had spent the previous several years convincing them to make it in the
    > first place, on spurious "security" grounds (which have never withstood
    > scrutiny). It's a self-fulfilling and entirely circular thing.


    But anyhow very useful is screening off a large amount of
    spam and badware.

    --
    Peter Håkanson
    IPSec Sverige ( At Gothenburg Riverside )
    Sorry about my e-mail address, but i'm trying to keep spam out,
    remove "icke-reklam" if you feel for mailing me. Thanx.

+ Reply to Thread