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 ; "D. Stussy" wrote: > 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 ...

+ Reply to Thread
Page 2 of 5 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 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-classcitizens.

    "D. Stussy" wrote:
    > 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.


    Aside from cases where CNAMEs are prohibited, CNAMEs are also avoided
    entirely by some, since they force resolvers to do extra work that can
    instead be done on the authoritative server side, so less traffic is
    used, and resolvers have less work to do.


    paul

  2. 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").


    You are aware that "forged" means something entirely different from
    "badly configured", aren't you?


    paul

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

    On Mon, 26 Jan 2004, Barry Margolin wrote:
    > 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.


    1) Zone name: True, CNAME LHSs can't appear as SOA LHSs, but to require that a
    zone has an SOA is only a property of a TLD. If I wanted to define "q.net" as a
    cname for "1.2.3.4.isp.net", I could - at least within the rules of DNS. Domain
    registrars COULD do this. The fact that they don't is another shortcoming, but
    not of the DNS structure.

    2) Target of NS and MX: True, but there would be another name out there that
    could be used - the ISP assigned dummy name, which does possess an A record and
    does have a PTR record pointing back to it. Why isn't that the canonical name?

    > > 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.


    Then why have a CNAME RR at all? If one can have multiple canonical hostnames
    for a host, there's no need for CNAME. Go ahead and let all 10k records point
    to the IP address - and "God forbid" you should have to move that machine to a
    new IP.

    > > 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).


    That's why one checks both. It is presumedly more unlikely that something is
    being spoofed or misconfigured if there is consistency. Consistency means that
    either both datasets are "properly" configured and/or they have been equally
    compromised.

    > 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.


    Remember that it is not the case where the PTR record doesn't exist that is the
    problem - but the case where the PTR record cannot resolve to the (canonical)
    hostname that one started with - but only to OTHER values.

    > 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.


    They don't have to actually delegate the reverse zone if they care to administer
    it properly themselves. That ground has already been covered in this thread.
    As I said, I don't care that "your" site is covered by a DEFECTIVE contract with
    your ISP regarding its DNS; that is your problem and I'm not going to make it
    mine. What people will and won't do does not equate to what they can and can't
    or should and shouldn't. Those limitations are not limitations of the DNS
    system - but use (or misuse) by people.

    It doesn't matter if I start with a name or an address. After two lookups (one
    forward and one reverse), I should be able to get back to the value I started
    with if the system is consistent (for some combination of each, if one-to-many
    mappings are present). Only consistent systems can have their identity trusted
    (to the extent that a domain name or IP address confers or is used in further
    identity checks with certificates, etc...). Unless you want to suggest that all
    mail servers MUST accept all mail delivered to them regardless of the identity
    of the incoming client (i.e. what the authenticator "is" [as opposed to "has" or
    "can do"]), then I see no reason why they shouldn't demand the DNS consistency
    that is being discussed. That's where this thread started.

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

    On Mon, 26 Jan 2004, Paul Jarc wrote:
    > 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.


    Although that's true, that's not included in what I have said.

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

    JdeBP> [...] If the reverse lookup is created to map the IP
    JdeBP> address to _just one_ of the domain names, then the
    JdeBP> address->name mapping is _not the inverse_ of the
    JdeBP> name->address mapping. For the address->name mapping
    JdeBP> to be the inverse of the name->address mapping, it would
    JdeBP> have to list _all_ of the domain names.

    BM> No it doesn't.

    False. If it didn't, it wouldn't be the inverse.

    BM> When the mail server is checking whether the address might be
    BM> spoofed, it performs an address->name lookup. Then it performs
    BM> a name->address lookup on the name that it got in the first step,
    BM> and compares the result with the original address. All this
    BM> requires is *one* PTR record. There's absolutely no need for
    BM> all the other names to have corresponding PTR records; [...]

    .... and several reasons for not having them, as already mentioned; and,
    because those resource records don't exist, the address->name and
    name->address mappings are _not inverses_. Once again, you demonstrate my
    previous point whilst, ironically, trying to argue against it.

    Moreover, there is no requirement that the address->name->address mapping be
    an identity, or even exist at all. So the notion that underpins the process
    is flawed.

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

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

    DS> But in that case, the ISP's hostname for your address will be
    DS> the CANONICAL NAME of the host, and your own domain name an
    DS> ALIAS that should be CNAMEd, not A'ed to the address.

    False. Again: See the first paragraph of RFC 2181 section 10.

    That would also be pointlessly inefficient, since it would in most cases
    significantly increase the number of back end queries that a resolving proxy
    DNS server would need to issue to resolve one's own domain name.

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

    Yes. (It may be a server-side alias, of course, but you are clearly only
    thinking of client-side aliases.)

    DS> Remember that only a CANONICAL HOSTNAME is supposed to appear
    DS> on the LHS of an A-RR.

    There is no such requirement.

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

    That's not an address->name->address mapping, and not the check being
    discussed.

    DS> If [one has] to play tricks because [one's] domain name also has
    DS> an SOA record (and therefore cannot also be CNAMEd), then [one
    DS> needs] to have the reverse DNS function point back to [one's]
    DS> domain for it to be believable. By contract, [one doesn't] have
    DS> that right, so that's why I called [his/her] contract defective.

    Your appellation is unsupported because your argument is flawed. The notion
    that such a domain name is not "believable" is simply false. And you are
    still, here, talking about the wrong mapping.

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

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

    Which is false.

    DS> I never said that ALL mappings need return the original value
    DS> (that would DISALLOW CNAMES).

    Which is also false. Aliases would not be disallowed by such a hypothetical
    requirement. The address->name mapping would simply have to include the
    aliases as well.

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

    And it's still false. It's perfectly legitimate for an address->name->address
    lookup to not be an identity, or to not exist at all, there being no
    requirements to the contrary; so your assertion that this has to be either
    improper configuration or forgery is false.

    DS> Someone then asked for where that is stated in an RFC.

    Actually, more than one person did. And you didn't provide a reference when
    responding to any of them, even though at least one of them repeated the
    question. That's because there are no such references, which is in turn
    because the DNS is not as you describe it to be.

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

    BM> Are you talking about lots of names resolving to the same IP
    BM> address? [...]

    JdeBP> [...] If the reverse lookup is created to map the IP address
    JdeBP> to _just one_ of the domain names, then the address->name
    JdeBP> mapping is _not the inverse_ of the name->address mapping.
    JdeBP> For the address->name mapping to be the inverse of the
    JdeBP> name->address mapping, it would have to list _all_ of the
    JdeBP> domain names. As I said, practical considerations relating
    JdeBP> to response size limits [...] and the behaviours of most DNS
    JdeBP> client libraries encourage DNS administrators to _not_ do this.

    DS> Any administrator that set up his DNS in such a manner is
    DS> an idiot.

    In such a manner as what ? In the manner that Barry described with many
    domain names mapping to one IP address and that IP address mapping to a single
    domain name ? That's a perfectly legitimate thing to do, and not something to
    berate a DNS administrator for. It's also perfectly legitimate for the IP
    address to not map to any domain names at all.

    DS> See "CANONICAL NAME" and the use of the CNAME DNS RR.

    You don't understand either of those if you think that they support your
    case. See the first paragraph of RFC 2181 section 10.

    DS> Regardless, I did say that for the address->name->address
    DS> check, [...]

    The address->name->address check is flawed, because it relies upon things
    being true about published DNS data that are not actually required to be
    true. The address->name->address mapping is not required to be an identity,
    and is not even required to exist. You cannot use it as a basis for your
    argument. Arguing, as you are, that the DNS is required to operate in a
    particular way because that makes address->name->address checks work, and that
    address->name->address checks are valid because the DNS is required to work in
    that particular way, is circular.

    It's also false. The DNS is not required to work in that particular way, and
    address->name->address checks do not necessarily work.

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

    PJ> "Inverse" would mean that *every* A record had a matching
    PJ> PTR record.

    BM> True, but irrelevant.

    Not to this thread.

    BM> No one ever said that the reverse had to be an inverse of the
    BM> forward.

    False (alas!). Mr Stussy, for one, has asserted it over and over
    again in this very thread. Read
    ,
    ,
    , and
    .

    He's probably asserted it a few more times in the (
    ) 8 messages of his in this thread that I have yet to read. (-:

    BM> What matters is that the forward is an inverse of the
    BM> reverse, [...]

    That's not a requirement either, though.

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

    BM> CNAME records aren't always feasible.

    "CNAME" resource records are best avoided, in favour of server-side aliases.

    BM> You can't use them for the zone name, and you can't use
    BM> them as the target of NS and MX records.

    True. True. False.

    John Navas' analysis of the RFCs in answer to question 6.5 of the
    "comp.protocol.tcp-ip.domains" FAQ is correct. (Yes, it contradicts the
    preceding text. Yes, the FAQ document could have been edited better.)



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

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

    However, preventing such complaints is not actually a requirement, because the
    complaints are based upon an incorrect model of the DNS. There's no
    requirement that the IP address of a TCP service client have a mapping to one
    or more domain names. As I said before, there's merely a statistical
    correlation between IP addresses that have no address->name mapping and
    undesirable clients, which is not even a complete one.

  12. 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:
    > 1) Zone name: True, CNAME LHSs can't appear as SOA LHSs, but to require
    > that a
    > zone has an SOA is only a property of a TLD. If I wanted to define "q.net"
    > as a
    > cname for "1.2.3.4.isp.net", I could - at least within the rules of DNS.
    > Domain
    > registrars COULD do this. The fact that they don't is another shortcoming,
    > but
    > not of the DNS structure.


    So? What difference does it make where the limitation comes from? If
    you're designing an application, it has to work within the context of
    the actual Internet. You can't just read RFC's and ignore reality.

    > Then why have a CNAME RR at all? If one can have multiple canonical
    > hostnames
    > for a host, there's no need for CNAME. Go ahead and let all 10k records
    > point
    > to the IP address - and "God forbid" you should have to move that machine to
    > a
    > new IP.


    CNAME records are useful when you want to inherit all the records of a
    name in one fell swoop. They also make it easier to avoid having to
    update multiple records when something changes, as you point out. I
    recommend using them whenever feasible.

    > > > 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).

    >
    > That's why one checks both. It is presumedly more unlikely that something is
    > being spoofed or misconfigured if there is consistency. Consistency means
    > that
    > either both datasets are "properly" configured and/or they have been equally
    > compromised.


    It's likely that something is being spoofed if address->name->address
    doesn't match. But if name->address->name doesn't match, it's most
    likely because there are multiple names mapping to the address. This is
    not a property of the DNS architecture, it's a fact about the real world.

    > > 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.

    >
    > They don't have to actually delegate the reverse zone if they care to
    > administer
    > it properly themselves.


    Sorry, I assumed "delegate" would be recognized as shorthand for
    "delegate or customize", since it's clear that either would address the
    issue. The point is that many ISPs refuse to do either. They have a
    simple, unconfigurable reverse mapping for the address range they assign
    to customers.

    > That ground has already been covered in this thread.
    > As I said, I don't care that "your" site is covered by a DEFECTIVE contract
    > with
    > your ISP regarding its DNS; that is your problem and I'm not going to make it
    > mine. What people will and won't do does not equate to what they can and
    > can't
    > or should and shouldn't. Those limitations are not limitations of the DNS
    > system - but use (or misuse) by people.


    If you want to interoperate with everyone on the Internet, you have to
    deal with the policies of ISPs. You can't just live in your ideal world
    and ignore all the people whose ISPs are defective in your opinion.
    Especially if this defect exists in the majority of ISPs.

    > It doesn't matter if I start with a name or an address. After two lookups
    > (one
    > forward and one reverse), I should be able to get back to the value I started
    > with if the system is consistent (for some combination of each, if
    > one-to-many
    > mappings are present). Only consistent systems can have their identity
    > trusted
    > (to the extent that a domain name or IP address confers or is used in further
    > identity checks with certificates, etc...). Unless you want to suggest that
    > all
    > mail servers MUST accept all mail delivered to them regardless of the
    > identity
    > of the incoming client (i.e. what the authenticator "is" [as opposed to "has"
    > or
    > "can do"]), then I see no reason why they shouldn't demand the DNS
    > consistency
    > that is being discussed. That's where this thread started.


    I believe there's an RFC that actually says that you MUST NOT refuse
    mail just because the name in the HELO message doesn't match the name
    you get from a reverse lookup.

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

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

    "D. Stussy" wrote:
    > On Mon, 26 Jan 2004, Paul Jarc wrote:
    >> 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.

    >
    > Although that's true, that's not included in what I have said.


    Then can you explain what you meant by this?

    >>>> Remember that only a CANONICAL HOSTNAME is supposed to appear on
    >>>> the LHS of an A-RR.



    paul

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

    "D. Stussy" wrote:
    > 1) Zone name: True, CNAME LHSs can't appear as SOA LHSs, but to
    > require that a zone has an SOA is only a property of a TLD. If I
    > wanted to define "q.net" as a cname for "1.2.3.4.isp.net", I could -
    > at least within the rules of DNS.


    Sure, as long as q.net is not a separate zone. If it is a zone, then
    RFC1034 & RFC1035 say it gets an SOA record, regardless of whether
    it's a TLD.

    > the ISP assigned dummy name, which does possess an A record and does
    > have a PTR record pointing back to it. Why isn't that the canonical
    > name?


    What do you mean by "canonical name"? I know how the RFCs define it,
    but your usage isn't consistent with that definition.

    > If one can have multiple canonical hostnames for a host, there's no
    > need for CNAME.


    Exactly right. Everything that can be done with CNAMEs can also be
    done without them.

    > "God forbid" you should have to move that machine to a new IP.


    CNAMEs provide indirection, and indirection is useful, but CNAMEs also
    force the work of processing the indirection onto resolvers. Some of
    us prefer to keep the indirection on the authoritative server, and
    automatically generate many A records there, so resolvers have less
    work to do. Then, if the address changes, we just regenerate our
    records. This is a simple matter of scripting.

    > I see no reason why they shouldn't demand the DNS consistency that
    > is being discussed.


    You can demand it all you like, but it isn't, and won't be, provided,
    nor is it required by the RFCs.


    paul

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

    In article <40152C35.57C9D124@Tesco.NET>,
    Jonathan de Boyne Pollard wrote:

    > PJ> "Inverse" would mean that *every* A record had a matching
    > PJ> PTR record.
    >
    > BM> True, but irrelevant.
    >
    > Not to this thread.


    This thread is about what it means to have properly set up DNS, to avoid
    software claiming that your DNS is forged. And that doesn't require
    that forward and reverse DNS be inverses.

    >
    > BM> No one ever said that the reverse had to be an inverse of the
    > BM> forward.
    >
    > False (alas!). Mr Stussy, for one, has asserted it over and over
    > again in this very thread. Read


    Who cares what random Usenet posters assert? I meant no one specifying
    requirements for the Internet.

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

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

    In article <40153577.C2FF4738@Tesco.NET>,
    Jonathan de Boyne Pollard wrote:

    > BM> If the ISP refuses to customize your reverse DNS, they usually
    > BM> have it set to point to a name in their own domain (typically
    > BM> some generic pattern, like cust-123-456.cable.isp.net), and
    > BM> they ensure that there's matching forward DNS. This is all
    > BM> that should be needed to prevent complaints of forged DNS data.
    >
    > However, preventing such complaints is not actually a requirement, because the
    > complaints are based upon an incorrect model of the DNS. There's no
    > requirement that the IP address of a TCP service client have a mapping to one
    > or more domain names. As I said before, there's merely a statistical
    > correlation between IP addresses that have no address->name mapping and
    > undesirable clients, which is not even a complete one.


    Actually, the DNS specification says that the name in a PTR record must
    be a primary name. And the definition of a primary name is the name in
    an A record.

    Furthermore, while there are many practical problems preventing all A
    records from having corresponding PTR records, the converse is not true.
    Any good DNS administrator should be able to arrange for the
    address->name->address mapping to be an identity, modulo occasional
    timing issues when DNS is being updated.

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

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

    DS> to require that a zone has an SOA is only a property of a TLD.

    TLDs have little to do with it. Requiring that a "zone" has an "SOA"
    resource record for its apex is done by DNS server softwares. (With
    some softwares, it's how they actually recognise "zone" apices in the
    first place.)

    DS> If I wanted to define "q.net" as a cname for "1.2.3.4.isp.net",
    DS> I could - at least within the rules of DNS.

    .... as long as you didn't want it to also be a delegation point. A
    domain name cannot be both a delegation point and a client-side alias.

    DS> Domain registrars COULD do this. The fact that they don't
    DS> is another shortcoming, but not of the DNS structure.

    Ironically, it's not solely the registries and registrars that prevent
    this from happening. Even if a registry _were_ to publish such DNS
    data, some people would refuse to recognise and accept those data.



    DS> Then why have a CNAME RR at all? If one can have multiple canonical
    DS> hostnames for a host, there's no need for CNAME. Go ahead and let
    DS> all 10k records point to the IP address - and "God forbid" you
    DS> should have to move that machine to a new IP.

    Server-side aliases are indeed preferable to client-side aliases. How
    easy it is to modify a set of server-side aliases in unison depends
    from the particular server-side aliasing mechanism that the software
    provides. For at least a few such mechanisms changing 10000 records
    in unison is a simple exercise. (To pick just one example: It's a
    trivial one-line modification if one is using "djbdns" and a template
    to generate those 10000 records.)

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

    DS> It is presumedly more unlikely that something is being spoofed
    DS> or misconfigured if there is consistency. Consistency means
    DS> that either both datasets are "properly" configured and/or they
    DS> have been equally compromised.

    However, a "properly configured" set of data can also be inconsistent.
    There is no requirement for consistency.

    DS> Remember that it is not the case where the PTR record doesn't
    DS> exist that is the problem [...]

    That causes problems for address->name->address checks just as equally.

    DS> As I said, I don't care that "your" site is covered by a
    DS> DEFECTIVE contract with your ISP regarding its DNS; that is
    DS> your problem and I'm not going to make it mine.

    It's actually you who is the root cause of the problem, however, since
    you attempt to enforce (by ostracism and by proselytisation) a model
    of DNS that doesn't match either its design or how it operates in
    practice.

    DS> It doesn't matter if I start with a name or an address. After
    DS> two lookups (one forward and one reverse), I should be able to
    DS> get back to the value I started with if the system is consistent [...]

    The data published are not consistent, are not required to be
    consistent, and have good reasons not to be consistent. So your
    argument is based upon a false premise.

    DS> Only consistent systems can have their identity trusted [...]

    .... the consequence of which is thus that one cannot use the DNS in
    this manner as a mechanism for determining identity.

    DS> Unless you want to suggest that all mail servers MUST accept all
    DS> mail delivered to them regardless of the identity of the incoming
    DS> client [...]

    You're creating a straw man.

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

    On Mon, 26 Jan 2004 15:55:55 GMT, "D. Stussy"
    wrote:

    >Only consistent systems can have their identity trusted
    >(to the extent that a domain name or IP address confers or is used in further
    >identity checks with certificates, etc...). Unless you want to suggest that all
    >mail servers MUST accept all mail delivered to them regardless of the identity
    >of the incoming client (i.e. what the authenticator "is" [as opposed to "has" or
    >"can do"]), then I see no reason why they shouldn't demand the DNS consistency
    >that is being discussed. That's where this thread started.


    In my opinion the real problem is not if the rule you
    are exposing is meaningful or not (I think it's not,
    by the way) but the very fact that you can decide what
    are the rules you can apply for dropping mail that is
    *not directed to you*.

    To have email to be guaranteed to get to a reasonable
    level of usability there should be at the very minumum
    *common* rules and *personal liability* for not
    respecting them. No. That reverse DNS must do what you
    want it to do is not a common rule. It never has been
    that way. Discussing if it's logical or not is
    completely missing the point.

    Inventing your own rules about what are the properties
    an email message must satisfy to be delivered you are
    making to the email system no less damage that who wants
    to use it to ask to a million people if they want to
    buy viagra pills. With your rules added the mail system
    didn't become better, but worse.

    Unfortunately there is nothing much that can be done
    against people that sends out millions of email to
    sell viagra pills or just steal credit card numbers,
    and nothing much can be done to self declared savers of
    the world that are just making the mess worse like you.

    The problem is not technical, but political.

    Spammers do no respect the mail system because they
    abuse it by throwing rubbish in it. You are not
    respecting the mail system either, because you do not
    really care if the mail you are dropping are rubbish
    or not, or if the rule you require to be satisfied
    can reasonably be satisfied or not.
    There are admins dropping mail from alleged dynamic
    IPs, from Asia, from USA, or in perfectly valid HTML
    format; no one should be allowed to do that to a mail
    message that is not directed to him/her.

    The real problem is that important empowered people
    do not *really* care about getting rid of spammers
    or of you. They don't really care about email.

    Jailing you if you destroy a personal message that
    was not directed to you *may be* is a possibility.
    Jailing who throw rubbish in the mail boxes may be
    is a possibility.

    Instead we *still* live in a world where anyone can
    self proclaim an administrator and get his/her hands
    on control other people beyond their will inventing
    rules that just please him/her. IMO this will soon
    or late change in civil worlds.

    You should not be able to decide what are the mail
    message that someone else can receive. Basically
    because you are no one and the power you have (if
    you are a mail administrator for other people) is
    only based on ignorance.

    You like the power, you should instead feel like who
    distributes the water or the electricity.
    They don't have any power of decision and this is
    absolutely good. If someone remains without water
    or electricity they risk consequences *even if it
    was not intentional* but for example just lack of
    control; and this is absolutely good too.

    You are saying instead that is ok intentionally
    depriving people from using the email system by
    forging your own rules even if you apparently know
    that there are legitimate users out there that do
    not fit your scheme.

    On the internet we're still at the barbarian level.
    But I'm optimist and IMO one day we will become
    a society. And people behaving like you will end
    up being in jail. And that's good too.

    Andrea

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

    On Mon, 26 Jan 2004, Paul Jarc wrote:
    > "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.


    No kidding. Had you bothered to read the history of the thread instead of
    jumping into the middle, you would find that was already covered. It doesn't
    matter if it's N->A->N or A->N->A; what matters is that there is some
    combination of results that gets one back to the same value that one started
    with.

    > 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.


    NO - a mail server, per the RFCs, may NOT do that. The RFC's state that the
    HELO hostname cannot be used in that manner. [I do believe that in the special
    case where the remote give YOUR server's hostname and it is not your server,
    that should be rejected, but the RFCs don't even technically permit that.]

    I do not believe that it is going too far to expect the names to match. An A
    record is supposed to be "owned" by a canonical hostname. A PTR record is
    supposed to have a canonical hostname as its value. Other names for that host
    (and interface, if multihomed) are ALIASES which are supposed to be on CNAME
    records. Granted that canonical does not mean unique, but it does mean
    authoritative. How can it be authoritative if using the name to get an address
    does not lead back to that name when looking up by address but instead, reports
    a different name? Was that an authoritative name (or address), or was that a
    spoofed entry?

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