Re: Some foolish ISPs treat other ISPs' customers as third-class citizens. - TCP-IP

This is a discussion on Re: Some foolish ISPs treat other ISPs' customers as third-class citizens. - TCP-IP ; DS> the DNS data will not be consistent across forward and DS> reverse lookups, and your site will be reported as DS> having "forged DNS data." It will only be reported as such by badly written softwares written by people ...

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast
Results 1 to 20 of 96

Thread: Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

  1. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    DS> the DNS data will not be consistent across forward and
    DS> reverse lookups, and your site will be reported as
    DS> having "forged DNS data."

    It will only be reported as such by badly written softwares written by people
    who don't understand DNS. There is no requirement that all IP addresses have
    mappings to domain names (and indeed many have not), and there is no
    requirement that the address->name and name->address mappings published in the
    public DNS database be inverses of each other. (Indeed, practical
    considerations relating to response size limits and the behaviours of most DNS
    client libraries encourage DNS administrators to _not_ make the address->name
    mappings the inverses of the name->address mappings.)

    Reporting as "forgery" the fact that an address->name->address mapping is not
    an identity, for a given IP address, is wrong.

  2. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    In article <4011E0AF.B87DE13F@Tesco.NET>,
    Jonathan de Boyne Pollard wrote:

    > Reporting as "forgery" the fact that an address->name->address mapping is not
    > an identity, for a given IP address, is wrong.


    Sendmail puts "may be forged" in the Received header in these cases.
    It's not saying that it is forged, just that it couldn't verify the
    veracity of the reverse lookup. It could be forged, but it could be
    just incompetence on the part of the DNS administrator.

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

  3. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    In article <4011E0AF.B87DE13F@Tesco.NET>,
    Jonathan de Boyne Pollard wrote:

    > (Indeed, practical
    > considerations relating to response size limits and the behaviours of most DNS
    > client libraries encourage DNS administrators to _not_ make the address->name
    > mappings the inverses of the name->address mappings.)


    What practical considerations are you referring to? Are you talking
    about lots of names resolving to the same IP address? That's not a
    problem -- you only need one PTR record for the address. As long as the
    reverse lookup finds one of those names, everything should be fine.

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

  4. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    In article ,
    Barry Margolin wrote:

    > What practical considerations are you referring to? Are you talking
    > about lots of names resolving to the same IP address? That's not a
    > problem -- you only need one PTR record for the address. As long as the
    > reverse lookup finds one of those names, everything should be fine.


    An ISP with 10000 customer domains mapping to the same IP address is
    certainly not going to include the 10000 domain names in the reply to
    a reverse lookup of the IP address.

    --
    Göran Larsson http://www.mitt-eget.com/

  5. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    JdeBP> Reporting as "forgery" the fact that an
    JdeBP> address->name->address mapping is not an identity,
    JdeBP> for a given IP address, is wrong.

    BM> Sendmail puts "may be forged" in the Received header in
    BM> these cases.

    He wasn't necessarily talking about Sendmail. The string that he gave was
    "forged DNS data", moreover.

    BM> It could be forged, but it could be just incompetence
    BM> on the part of the DNS administrator.

    Labelling the DNS administrator "incompetent" is just as wrong
    as labelling the DNS data "forged".

  6. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    JdeBP> There is no requirement that [...] the address->name and
    JdeBP> name->address mappings published in the public DNS database
    JdeBP> be inverses of each other. (Indeed, practical considerations
    JdeBP> relating to response size limits and the behaviours of most
    JdeBP> DNS client libraries encourage DNS administrators to _not_
    JdeBP> make the address->name mappings the inverses of the
    JdeBP> name->address mappings.)

    BM> What practical considerations are you referring to?

    The ones mentioned, amongst others.

    BM> Are you talking about lots of names resolving to the same IP
    BM> address? That's not a problem -- you only need one PTR record
    BM> for the address. As long as the reverse lookup finds one of
    BM> those names, everything should be fine.

    It is a problem; and you have unwittingly exemplified precisely the (first)
    sort of practical consideration that I have mentioned, ironically whilst
    trying to demonstrate that it doesn't exist. If the reverse lookup is created
    to map the IP address to _just one_ of the domain names, then the
    address->name mapping is _not the inverse_ of the name->address mapping. For
    the address->name mapping to be the inverse of the name->address mapping, it
    would have to list _all_ of the domain names. As I said, practical
    considerations relating to response size limits (Have you performed a reverse
    lookup for 64.156.26.16 lately? How many web hosting services host twenty
    times that number of web sites on a single IP address? How many forward DNS
    lookups would Mr Stussy's hyothetical software have to perform for its
    complete address->name->address check if a client connected from this IP
    address?) and the behaviours of most DNS client libraries encourage DNS
    administrators to _not_ do this.

  7. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    In article <40126487.69F9B991@Tesco.NET>,
    Jonathan de Boyne Pollard wrote:

    > It is a problem; and you have unwittingly exemplified precisely the (first)
    > sort of practical consideration that I have mentioned, ironically whilst
    > trying to demonstrate that it doesn't exist. If the reverse lookup is created
    > to map the IP address to _just one_ of the domain names, then the
    > address->name mapping is _not the inverse_ of the name->address mapping. For
    > the address->name mapping to be the inverse of the name->address mapping, it
    > would have to list _all_ of the domain names.


    No it doesn't. When the mail server is checking whether the address
    might be spoofed, it performs an address->name lookup. Then it performs
    a name->address lookup on the name that it got in the first step, and
    compares the result with the original address. All this requires is
    *one* PTR record. There's absolutely no need for all the other names to
    have corresponding PTR records; if there are other A records with the
    same address, there's no way to detect them, so they can't cause a
    problem

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

  8. Re: Some foolish ISPs treat other ISPs' customers as third-classcitizens.

    Barry Margolin wrote:
    > When the mail server is checking whether the address might be
    > spoofed, it performs an address->name lookup. Then it performs a
    > name->address lookup on the name that it got in the first step, and
    > compares the result with the original address. All this requires is
    > *one* PTR record.


    Right. But Jonathan is right too, because this alone is not enough to
    make the reverse mapping an inverse of the forward mapping. "Inverse"
    would mean that *every* A record had a matching PTR record.

    > There's absolutely no need for all the other names to have
    > corresponding PTR records


    Right, and that's (part of) what Jonathan is saying.


    paul

  9. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    In article ,
    prj@po.cwru.edu (Paul Jarc) wrote:

    > Barry Margolin wrote:
    > > When the mail server is checking whether the address might be
    > > spoofed, it performs an address->name lookup. Then it performs a
    > > name->address lookup on the name that it got in the first step, and
    > > compares the result with the original address. All this requires is
    > > *one* PTR record.

    >
    > Right. But Jonathan is right too, because this alone is not enough to
    > make the reverse mapping an inverse of the forward mapping. "Inverse"
    > would mean that *every* A record had a matching PTR record.


    True, but irrelevant. No one ever said that the reverse had to be an
    inverse of the forward. What matters is that the forward is an inverse
    of the reverse, i.e. that every PTR record has a matching A record.
    This is relatively easy to ensure (unless spoofing is actually taking
    place, of course), and should suppress any warnings about forged names.

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

  10. Re: Some foolish ISPs treat other ISPs' customers as third-classcitizens.

    Barry Margolin wrote:
    > No one ever said that the reverse had to be an inverse of the
    > forward.


    D. Stussy did. That's how the thread started - or at least, how it
    migrated to comp.protocols.tcp-ip.domains - and that's what Jonathan
    was responding to.

    > What matters is that the forward is an inverse of the reverse,
    > i.e. that every PTR record has a matching A record.


    That's certainly good practice, but not required AFAIK. If it doesn't
    hold, that's still no evidence of forgery, nor necessarily
    incompetence.


    paul

  11. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    In article ,
    prj@po.cwru.edu (Paul Jarc) wrote:

    > Barry Margolin wrote:
    > > No one ever said that the reverse had to be an inverse of the
    > > forward.

    >
    > D. Stussy did. That's how the thread started - or at least, how it
    > migrated to comp.protocols.tcp-ip.domains - and that's what Jonathan
    > was responding to.


    I found the first message that mentioned "forged DNS data" (it was
    before comp.protocols.tcp-ip.domains was added). It said:

    > Then you have a defective contract and are being screwed. If they refuse to
    > set
    > your reverse lookup to your domain name, you are in even worse situation
    > since
    > the DNS data will not be consistent across forward and reverse lookups, and
    > your
    > site will be reported as having "forged DNS data."


    This is generally incorrect. If the ISP refuses to customize your
    reverse DNS, they usually have it set to point to a name in their own
    domain (typically some generic pattern, like
    cust-123-456.cable.isp.net), and they ensure that there's matching
    forward DNS. This is all that should be needed to prevent complaints of
    forged DNS data.

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

  12. Re: Some foolish ISPs treat other ISPs' customers as third-classcitizens.

    On Sat, 24 Jan 2004, Goran Larsson wrote:
    > In article ,
    > Barry Margolin wrote:
    >
    > > What practical considerations are you referring to? Are you talking
    > > about lots of names resolving to the same IP address? That's not a
    > > problem -- you only need one PTR record for the address. As long as the
    > > reverse lookup finds one of those names, everything should be fine.

    >
    > An ISP with 10000 customer domains mapping to the same IP address is
    > certainly not going to include the 10000 domain names in the reply to
    > a reverse lookup of the IP address.


    I seriously doubt that in such an instance, the ISP is going to have 10k A
    records in the DNS - instead of 9,999 CNAMES pointing to the TRUE name of the
    host, and ONE A-RR for the address.

  13. Re: Some foolish ISPs treat other ISPs' customers as third-classcitizens.

    On Sat, 24 Jan 2004, Jonathan de Boyne Pollard wrote:
    > JdeBP> There is no requirement that [...] the address->name and
    > JdeBP> name->address mappings published in the public DNS database
    > JdeBP> be inverses of each other. (Indeed, practical considerations
    > JdeBP> relating to response size limits and the behaviours of most
    > JdeBP> DNS client libraries encourage DNS administrators to _not_
    > JdeBP> make the address->name mappings the inverses of the
    > JdeBP> name->address mappings.)
    >
    > BM> What practical considerations are you referring to?
    >
    > The ones mentioned, amongst others.
    >
    > BM> Are you talking about lots of names resolving to the same IP
    > BM> address? That's not a problem -- you only need one PTR record
    > BM> for the address. As long as the reverse lookup finds one of
    > BM> those names, everything should be fine.
    >
    > It is a problem; and you have unwittingly exemplified precisely the (first)
    > sort of practical consideration that I have mentioned, ironically whilst
    > trying to demonstrate that it doesn't exist. If the reverse lookup is created
    > to map the IP address to _just one_ of the domain names, then the
    > address->name mapping is _not the inverse_ of the name->address mapping. For
    > the address->name mapping to be the inverse of the name->address mapping, it
    > would have to list _all_ of the domain names. As I said, practical
    > considerations relating to response size limits (Have you performed a reverse
    > lookup for 64.156.26.16 lately? How many web hosting services host twenty
    > times that number of web sites on a single IP address? How many forward DNS
    > lookups would Mr Stussy's hyothetical software have to perform for its
    > complete address->name->address check if a client connected from this IP
    > address?) and the behaviours of most DNS client libraries encourage DNS
    > administrators to _not_ do this.


    Any administrator that set up his DNS in such a manner is an idiot. See
    "CANONICAL NAME" and the use of the CNAME DNS RR.

    Regardless, I did say that for the address->name->address check, there only
    needs to be included SOME result for which that returns the same address as one
    started with. Note that I never said it need be true for ALL results. Either
    or both mappings can be one-to-many.

  14. Re: Some foolish ISPs treat other ISPs' customers as third-classcitizens.

    On Sun, 25 Jan 2004, Paul Jarc wrote:
    > Barry Margolin wrote:
    > > When the mail server is checking whether the address might be
    > > spoofed, it performs an address->name lookup. Then it performs a
    > > name->address lookup on the name that it got in the first step, and
    > > compares the result with the original address. All this requires is
    > > *one* PTR record.

    >
    > Right. But Jonathan is right too, because this alone is not enough to
    > make the reverse mapping an inverse of the forward mapping. "Inverse"
    > would mean that *every* A record had a matching PTR record.
    >
    > > There's absolutely no need for all the other names to have
    > > corresponding PTR records

    >
    > Right, and that's (part of) what Jonathan is saying.


    That is not how I read his replies.

  15. Re: Some foolish ISPs treat other ISPs' customers as third-classcitizens.

    On Sun, 25 Jan 2004, Paul Jarc wrote:
    > Barry Margolin wrote:
    > > No one ever said that the reverse had to be an inverse of the
    > > forward.

    >
    > D. Stussy did. That's how the thread started - or at least, how it
    > migrated to comp.protocols.tcp-ip.domains - and that's what Jonathan
    > was responding to.


    Then you too misread. I said that there needs to be SOME mapping by the
    "reverse" function that returns the original value put to the "forward" function
    for things to be valid (i.e. "not forged"). I never said that ALL mappings need
    return the original value (that would DISALLOW CNAMES). Anyone who thought so
    needs to go back and re-read what I said carefully, else be branded an idiot.

    > > What matters is that the forward is an inverse of the reverse,
    > > i.e. that every PTR record has a matching A record.

    >
    > That's certainly good practice, but not required AFAIK. If it doesn't
    > hold, that's still no evidence of forgery, nor necessarily
    > incompetence.


    ....And as that relates to mail servers when they do the lookup, if they do not
    find the data to be so, they know that the client site that is trying to connect
    to them is either not properly configured (i.e. NOT good practice) or is NOT
    whom they say they are (i.e. forged), and thus there is CAUSE to REFUSE the
    incoming mail. That's what I originally said.

    Someone then asked for where that is stated in an RFC. Why would it have to be
    in one? Some things are just simply common sense - obviously a trait that is
    lacking among some (many?) here on the Internet.

  16. Re: Some foolish ISPs treat other ISPs' customers as third-classcitizens.

    On Mon, 26 Jan 2004, Barry Margolin wrote:
    > In article ,
    > prj@po.cwru.edu (Paul Jarc) wrote:
    > > Barry Margolin wrote:
    > > > No one ever said that the reverse had to be an inverse of the
    > > > forward.

    > >
    > > D. Stussy did. That's how the thread started - or at least, how it
    > > migrated to comp.protocols.tcp-ip.domains - and that's what Jonathan
    > > was responding to.

    >
    > I found the first message that mentioned "forged DNS data" (it was
    > before comp.protocols.tcp-ip.domains was added). It said:
    >
    > > Then you have a defective contract and are being screwed. If they refuse to
    > > set
    > > your reverse lookup to your domain name, you are in even worse situation
    > > since
    > > the DNS data will not be consistent across forward and reverse lookups, and
    > > your
    > > site will be reported as having "forged DNS data."

    >
    > This is generally incorrect. If the ISP refuses to customize your
    > reverse DNS, they usually have it set to point to a name in their own
    > domain (typically some generic pattern, like
    > cust-123-456.cable.isp.net), and they ensure that there's matching
    > forward DNS. This is all that should be needed to prevent complaints of
    > forged DNS data.


    But in that case, the ISP's hostname for your address will be the CANONICAL NAME
    of the host, and your own domain name an ALIAS that should be CNAMEd, not A'ed
    to the address. (Remember that you don't have access to the reverse DNS
    function data per your defective ISP contract....)

    If one has "domain.com" A-> .address. PTR-> "Dummyname.ISP.NET", then:

    1) Is "domain.com" a true name for the host, i.e. not an alias? ...Especially
    where "Dummyname.ISP.NET" does map back to .address. via an A-RR? Remember that
    only a CANONICAL HOSTNAME is supposed to appear on the LHS of an A-RR.

    2) If one cannot derive "domain.com" from the given .address. (or get back to
    ..address. from "Dummyname.ISP.NET") then how do we know that we are really
    talking to whom we think we are? Cf. "Sanity check."

    If you have to play tricks because your domain name also has an SOA record (and
    therefore cannot also be CNAMEd), then you need to have the reverse DNS function
    point back to your domain for it to be believable. By contract, you don't have
    that right, so that's why I called your contract defective.

  17. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    In article ,
    "D. Stussy" wrote:

    > On Sat, 24 Jan 2004, Goran Larsson wrote:
    > > In article ,
    > > Barry Margolin wrote:
    > >
    > > > What practical considerations are you referring to? Are you talking
    > > > about lots of names resolving to the same IP address? That's not a
    > > > problem -- you only need one PTR record for the address. As long as the
    > > > reverse lookup finds one of those names, everything should be fine.

    > >
    > > An ISP with 10000 customer domains mapping to the same IP address is
    > > certainly not going to include the 10000 domain names in the reply to
    > > a reverse lookup of the IP address.

    >
    > I seriously doubt that in such an instance, the ISP is going to have 10k A
    > records in the DNS - instead of 9,999 CNAMES pointing to the TRUE name of the
    > host, and ONE A-RR for the address.


    Actually, it's quite common to use multiple A records. Especially when
    you want to be able to use the domain itself as a hostname, not just
    www., because the zone name can't be a CNAME. In that case you
    might have 10,000 A records and 10,000 CNAME records:

    foo.com. A 1.2.3.4
    www.foo.com. CNAME foo.com.
    bar.net. A 1.2.3.4
    www.bar.net. CNAME bar.net.
    ....

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

  18. Re: Some foolish ISPs treat other ISPs' customers as third-class citizens.

    In article ,
    "D. Stussy" wrote:

    > On Mon, 26 Jan 2004, Barry Margolin wrote:
    > > In article ,
    > > prj@po.cwru.edu (Paul Jarc) wrote:
    > > > Barry Margolin wrote:
    > > > > No one ever said that the reverse had to be an inverse of the
    > > > > forward.
    > > >
    > > > D. Stussy did. That's how the thread started - or at least, how it
    > > > migrated to comp.protocols.tcp-ip.domains - and that's what Jonathan
    > > > was responding to.

    > >
    > > I found the first message that mentioned "forged DNS data" (it was
    > > before comp.protocols.tcp-ip.domains was added). It said:
    > >
    > > > Then you have a defective contract and are being screwed. If they refuse
    > > > to
    > > > set
    > > > your reverse lookup to your domain name, you are in even worse situation
    > > > since
    > > > the DNS data will not be consistent across forward and reverse lookups,
    > > > and
    > > > your
    > > > site will be reported as having "forged DNS data."

    > >
    > > This is generally incorrect. If the ISP refuses to customize your
    > > reverse DNS, they usually have it set to point to a name in their own
    > > domain (typically some generic pattern, like
    > > cust-123-456.cable.isp.net), and they ensure that there's matching
    > > forward DNS. This is all that should be needed to prevent complaints of
    > > forged DNS data.

    >
    > But in that case, the ISP's hostname for your address will be the CANONICAL
    > NAME
    > of the host, and your own domain name an ALIAS that should be CNAMEd, not
    > A'ed
    > to the address. (Remember that you don't have access to the reverse DNS
    > function data per your defective ISP contract....)


    CNAME records aren't always feasible. You can't use them for the zone
    name, and you can't use them as the target of NS and MX records.

    > If one has "domain.com" A-> .address. PTR-> "Dummyname.ISP.NET", then:
    >
    > 1) Is "domain.com" a true name for the host, i.e. not an alias?


    It's one of several names for the host.

    > ...Especially
    > where "Dummyname.ISP.NET" does map back to .address. via an A-RR? Remember
    > that
    > only a CANONICAL HOSTNAME is supposed to appear on the LHS of an A-RR.


    I know of no such rule.

    > 2) If one cannot derive "domain.com" from the given .address. (or get back
    > to
    > .address. from "Dummyname.ISP.NET") then how do we know that we are really
    > talking to whom we think we are? Cf. "Sanity check."


    Validity checks are generally only needed when you're checking an
    *incoming* connection against an access list. If the access list says
    "Permit foo.bar.com", you have to protect yourself against the fact that
    anyone can put a PTR records pointing to foo.bar.com in a reverse domain
    they control. The validity check depends on the fact that a spoofer
    would not have control over the domain that he's spoofing (if he does,
    he's not really a spoofer).

    While I suppose there are some times when you might want to do a sanity
    check when you're making an outgoing connection, it's not really
    necessary and is generally not practical. If a DNS administrator enters
    an incorrect A record, it will normally be detected at the application
    layer. For instance, if it's supposed to be the address of a web
    server, either there won't be an HTTP server running on the host, or it
    won't recognize the name in the "Host:" header of the request.

    There are many times when it's not feasible to ensure that A records
    have matching PTR records. We've already mentioned ISPs that don't
    provide custom reverse DNS for their static IP customers. Another case
    is domains like dyndns.org; these enter A records automatically for
    their users, but there's no way for them to control the corresponding
    reverse domains.

    So as much as you'd *like* forward and reverse DNS to be mirrors of each
    other, it's simply not possible to implement all the time. Application
    designers have to recognize the limitations, and not implement features
    that won't work in the real world. It's a known fact that many ISPs
    won't delegate reverse DNS for individual IPs, and they're not going to
    change their policies just because someone distributes a mail server
    that depends on this.

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

  19. Re: Some foolish ISPs treat other ISPs' customers as third-classcitizens.

    Barry Margolin wrote:
    > In article ,
    > "D. Stussy" wrote:
    >> If one has "domain.com" A-> .address. PTR-> "Dummyname.ISP.NET", then:
    >>
    >> 1) Is "domain.com" a true name for the host, i.e. not an alias?

    >
    > It's one of several names for the host.
    >
    >> ...Especially where "Dummyname.ISP.NET" does map back to
    >> .address. via an A-RR? Remember that only a CANONICAL HOSTNAME is
    >> supposed to appear on the LHS of an A-RR.

    >
    > I know of no such rule.


    I think what he's saying is essentially the rule that a name cannot
    have both CNAME and A records. This example does not appear to
    violate that rule, since domain.com is described as having an A
    record, but is not described as having a CNAME record.


    paul

  20. Re: Some foolish ISPs treat other ISPs' customers as third-classcitizens.

    "D. Stussy" wrote:
    > I said that there needs to be SOME mapping by the "reverse" function
    > that returns the original value put to the "forward" function for
    > things to be valid (i.e. "not forged").


    So you're talking about name -> address -> name. But...

    > ...And as that relates to mail servers when they do the lookup, if
    > they do not find the data to be so, they know that the client site
    > that is trying to connect to them is either not properly configured
    > (i.e. NOT good practice) or is NOT whom they say they are
    > (i.e. forged), and thus there is CAUSE to REFUSE the incoming mail.


    In this situation, the mail server starts out with the client's
    address, not its name. The server can check address -> name ->
    address, but this is different from name -> address -> name.

    A mail server might check the HELO hostname and verify that there is
    an A record mapping that name to the client's address. The server
    might also look for a PTR record for the client's address, and verify
    that the pointed-to name has its own A record that maps to the same
    address. But it is going too far to expect the two names to match.


    paul

+ Reply to Thread
Page 1 of 5 1 2 3 ... LastLast