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 ; On Mon, 26 Jan 2004, Jonathan de Boyne Pollard wrote: > 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 ...

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

    On Mon, 26 Jan 2004, Jonathan de Boyne Pollard wrote:
    > 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.


    Then explain CNAMEs.

    If the LHS is not a canonical name, then it is an ALIAS that needs to be on a
    CNAME record LHS.

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


    It is true of the name->address->name mapping too.

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


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

    On Mon, 26 Jan 2004, Jonathan de Boyne Pollard wrote:
    > 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.


    True that aliases aren't disallowed by this. The fact that aliases aren't
    canonical names in themselves, and thus only appear on CNAME RRs - and are
    therefore forbidden from owning A RRs or appearing on the RHS of PTR RRs does
    disallow them.

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


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

    On Mon, 26 Jan 2004, Jonathan de Boyne Pollard wrote:
    > 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.


    In such a manner as to FAIL to list all the domain names that have A RRs for
    that address on the RHS of PTR RRs for that address.

    What you seem to miss is that if the address cannot resolve to a hostname for
    all hostnames that resolve to that address, then the hostnames that don't are
    really ALIASES that are supposed to be on CNAME RRs.

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


    I never said that it is required to exist. I said that if it does exist, then
    it needs to be consistent for it to be believable.

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


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

    On Mon, 26 Jan 2004, 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.
    >
    > BM> No one ever said that the reverse had to be an inverse of the
    > BM> forward.


    Close enough. I didn't technically say that EVERY lookup had to have its
    inverse listed - but that there needs to be at least ONE case, when DNS data
    exists at all, where it does for either one hostname or one IP address
    (depending on what one starts with) for the DNS data not to be considered a
    possible forgery by the mail server.

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


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


    As far as spoofing is concerned, there is no difference whether one starts with
    a name or one starts with an address. If there is no combination of lookups
    that can return the data value one started with (excluding the NULL set on the
    initial lookup), then the possibility that the name or address is spoofed (or
    incorrectly configured - the mail server typically doesn't care) is there.
    [Where the initial lookup returns a null result, it cannot lead to a "possibly
    forged" condition, but to the "no name/address" condition, which mail servers
    typically treat differently.]

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


    I would not. Some may choose to "customize" for their clients in a way that
    doesn't "delegate" (within the meaning of DNS, along with NS RRs to a sub-zone).

    That case, which I have called the "defective contract," is part of the issue.
    Where that is true, the ISP's name for the given, fixed address is going to be
    the canonical name, and anything else will be an ALIAS that should be on a CNAME
    RR (where possible). I agree that such is not universally possible (e.g. a zone
    that has an SOA record), but there are ways of configuring it so that we don't
    have the "brain dead" solution.

    Instead of (the bad solution):

    domain.com. SOA ...
    A 1.2.3.4

    They could simply have (the better solution):

    domain.com. SOA ...
    MX 0 w-x-y-z.isp.net.
    *.domain.com. CNAME w-x-y-z.isp.net.

    (and of course, somewhere else on the Internet, under the ISP's control):

    w-x-y-z.isp.net. A 1.2.3.4
    4.3.2.1.in-addr.arpa. PTR w-x-y-z.isp.net

    OK, so I used another dreaded construct, the wildcarded CNAME RR. However, that
    will lead to a construct that will fully satisfy the mail server without a
    "possibly forged" result. I will concede that things like "telnet domain.com"
    and URLs such as "http://domain.com" won't work (but an HTTP request to
    "www.domain.com" in most browsers will convert to a working request).

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


    Does that mean we should allow spam too - because some ISPs are spammer
    supporting or ignorant? That should sufficiently prove your point incorrect.

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


    The HELO issue has nothing to do with the issue being discussed. What we're
    talking about is the appropriateness of servers that disallow hosts that have
    "potentially forged" names from connecting because their reverse DNS lookup
    followed by a forward lookup of all (non NULL) results does not provide any
    mapping back to the address being used.


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

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


    1) That a DNS RR name appearing on the LHS of a CNAME RR cannot appear on the
    LHS of any other type of record (the true fact).

    2) That I had not said that fact (in #1) previously in this thread.

    What did you think I meant by "[a]lthough that's true, that's not included in
    what I have said[?]"

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


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

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


    OK, but the only things that HAVE to be separate zones are the TLDs and the DNS
    root.

    [Technically, we could CNAME one TLD to another, but since the DNS is supposed
    to be a distributed database, such would not be useful. I was willing to accept
    that the TLDs are separate zones as an axiom or by definition.]

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


    The TRUE name for a host/interface (to account for the multi-homed), as opposed
    to its ALIASES. Aliases go on CNAME records.

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


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

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


    ....And that MEANS that for some "address PTR-> name A-> address" lookup, where
    there is a non-null PTR return of data, some combination of that WILL lead back
    to the starting address (and the same if one starts with a name), and the DNS
    data will NOT be considered as "possibly forged" by the mail server.

    Remember that I never claimed that the double lookup ever be an "identity map"
    (i.e. that ALL combinations of results produce a consistent result) - only that
    ONE combination of results do. Per Mr. Margolin's quote, that is assured by the
    definition he paraphrased.

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


    Finally, someone who knows "good practice." :-)

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

    On Mon, 26 Jan 2004, Jonathan de Boyne Pollard wrote:
    > 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.


    No, it doesn't. Failure of the PTR record to resolve cannot yield the "possibly
    forged" condition.

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


    You will find that someone else on this thread has proven that wrong.

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


    And you're creating "hollow man."

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

    In article ,
    "D. Stussy" wrote:

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

    >
    > Close enough. I didn't technically say that EVERY lookup had to have its
    > inverse listed - but that there needs to be at least ONE case, when DNS data
    > exists at all, where it does for either one hostname or one IP address
    > (depending on what one starts with) for the DNS data not to be considered a
    > possible forgery by the mail server.


    But since some uses might start with a name, and others might start with
    an address, this implies that you do need all the inverses listed to
    meet your consistency criteria, doesn't it? In the name->address->name
    method, the DNS administrator can't predict which of the names some user
    will start with, so he has to be prepared for any of them.

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

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

    In article ,
    "D. Stussy" wrote:

    > As far as spoofing is concerned, there is no difference whether one starts
    > with
    > a name or one starts with an address.


    Yes, there is, because it relates to the nature of the threat you're
    trying to deal with by performing the consistency check. If someone
    were trying to make themselves appear to be microsoft.com, they could
    only modify the reverse DNS, because they don't have any control over
    the forward DNS; the consistency check detects this spoofing attempt.
    What danger is there if Microsoft points one of their A records to a
    network they don't control the reverse DNS of?

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

    >
    > I would not. Some may choose to "customize" for their clients in a way that
    > doesn't "delegate" (within the meaning of DNS, along with NS RRs to a
    > sub-zone).


    You "would not" do what?

    > That case, which I have called the "defective contract," is part of the issue.


    Like it or not, most consumer-grade ISPs don't provide any DNS
    customization. You generally need to purchase more expensive
    enterprise-grade service to get this feature.

    > They could simply have (the better solution):
    >
    > domain.com. SOA ...
    > MX 0 w-x-y-z.isp.net.
    > *.domain.com. CNAME w-x-y-z.isp.net.


    This will work if the ISP guarantees a stable naming scheme. When I was
    managing DNS for my former employer's DSL offering, we occasionally
    changed our naming scheme (e.g. switching from a single domain for all
    addresses to per-POP subdomains, to resolve some performance issues in
    the database application that generated the DNS files). We never
    officially documented our naming scheme, so we didn't notify customers
    of the changes. They were not expected to be using our names directly,
    they were just there to ensure that there was *some* DNS entry for every
    address.

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

    "D. Stussy" wrote:
    > It doesn't matter if it's N->A->N or A->N->A;


    It does. N->A->N cannot always be made to work for all names you
    might start with. A->N->A can almost always be made to work for any
    address you might start with, and it is good practice, but even that
    is not required.

    > Other names for that host (and interface, if multihomed) are ALIASES
    > which are supposed to be on CNAME records.


    The RFCs, and widespread existing practice, disagree with you. There
    is absolutely nothing incorrect about having multiple names all
    pointing to the same address via their own A records instead of
    CNAMEs.

    > Granted that canonical does not mean unique, but it does mean
    > authoritative.


    In the context of DNS, the definitions of "canonical" and
    "authoritative" are unrelated. Read RFC1034.

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


    You seem to be reading too much into the word "authoritative". It is
    not defined in terms of data consistency.


    paul

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

    "D. Stussy" wrote:
    > OK, but the only things that HAVE to be separate zones are the TLDs
    > and the DNS root.


    TLDs don't have to be zones. .arpa, for example, happens to be a
    zone, but has no particular need to be.

    > [Technically, we could CNAME one TLD to another, but since the DNS
    > is supposed to be a distributed database, such would not be useful.


    There are more choices for a domain (top-level or otherwise) than just
    zone or CNAME. Also, the distributed nature of DNS is irrelevant to
    whether a domain name has CNAME records.

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

    >
    > The TRUE name for a host/interface (to account for the multi-homed),
    > as opposed to its ALIASES.


    Your use of "the" implies that you think there can be only one such
    name. The RFCs, and widespread existing practice, disagree with you.
    You've been given refernces to RFCs which explain how reality is
    different from the way you imagine it to be. You have provided no
    references supporting your position. As long as you're not willing to
    learn, I no longer care about helping you in your DNS education.


    paul

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

    Barry Margolin wrote:

    (snip)

    > Yes, there is, because it relates to the nature of the threat you're
    > trying to deal with by performing the consistency check. If someone
    > were trying to make themselves appear to be microsoft.com, they could
    > only modify the reverse DNS, because they don't have any control over
    > the forward DNS; the consistency check detects this spoofing attempt.
    > What danger is there if Microsoft points one of their A records to a
    > network they don't control the reverse DNS of?


    Well, some web browser warn when a link points to a different
    domain than the page that is referencing it. It is useful to
    know the true name of a web server.

    The result, though, would be that Microsoft would seem to be
    responsible for something that didn't belong to them, which would
    not be in their interest. It doesn't seem to be as much of a
    problem as spoofing PTR records.

    Verifying reverse entries is useful for servers, verifying forward
    entries is useful for clients.

    -- glen


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

    Jonathan de Boyne Pollard wrote:

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


    >


    Well, that was in 1999. It is true that MX pointing to a CNAME for
    the highest priority (lowest number) MX doesn't cause any problems,
    and the common case of only one MX satisfies that.

    It seems, though, that is was enough of a problem (other MX pointing
    to CNAME) that BIND has been changed to disallow it. (Unless it has
    been changed back since I last knew.)

    -- glen


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

    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.


    The SunOS resolver used to verify every reverse lookup. I suppose it
    was easier to do that way than to do it inside every server.

    Even without that, many anonymous ftp servers and ssh servers do it.

    Preventing complaints from users unable to connect to ftp or ssh
    servers means that ISPs should supply verifiable reverse lookups.

    The cust-123-456.cable.isp.net type are fine, as there is even less
    work by the person reading the log to find the true IP address.

    -- glen


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

    In article <%_0Sb.135532$5V2.693254@attbi_s53>,
    glen herrmannsfeldt wrote:

    > Preventing complaints from users unable to connect to ftp or ssh
    > servers means that ISPs should supply verifiable reverse lookups.


    Right. But it doesn't require providing user-specified, customized
    reverse lookups. If the customer wishes to refer to their IP by the
    name www.myvanitydomain.com, it doesn't conflict with the generic
    reverse DNS that the ISP provides.

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

    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.

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

    gh> Well, that was in 1999.

    And it's as correct now as it was then. The RFCs haven't changed. RFC 2821
    was written in 2001, but it also agrees with John Navas (and with the other
    RFCs) about this.

    Client-side aliases are a poor idea, and should be avoided where possible.
    However, there is no prohibition of the domain name in the data portion of an
    "MX" resource record being a client-side alias.

    gh> It seems, though, that is was enough of a problem (other MX
    gh> pointing to CNAME) that BIND has been changed to disallow it.

    What makes you think that BIND actually has such a prohibition ? BIND has a
    prohibition on mixing CNAME resource records with non-empty resource record
    sets of any other types, but that's not what is being discussed here. There
    used to be a requirement that the domain portions of mailbox names not be
    client-side aliases (which of course wasn't a DNS server's place to enforce
    and so had nothing to do with BIND); but that requirement was lifted years ago
    (moving the responsibility for dealing with domain aliasing in virtual hosting
    from the SMTP Relay client to the MTS at the SMTP Relay server end, making it
    a purely internal MTS configuration matter), and that is _also_ not what is
    being discussed here.

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

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

    gh> The SunOS resolver [sic] used to verify every reverse lookup.

    And it did so based upon an incorrect model of the DNS. (Witness the number
    of people over the years who have complained about the spurious log entries,
    complaining about perfectly legitimate DNS data, that this behaviour causes.)

    gh> Even without that, many anonymous ftp servers and ssh
    gh> servers do it.

    And they do so (although I suspect that they don't -- SSH servers _certainly_
    have no need for such erroneous "security" measures) based upon an incorrect
    model of the DNS.

    gh> Preventing complaints from users unable to connect to ftp or
    gh> ssh servers means that ISPs should supply verifiable reverse
    gh> lookups.

    No. It means that the operators of those servers should learn how the DNS
    actually works.

    gh> The cust-123-456.cable.isp.net type are fine, as there is
    gh> even less work by the person reading the log to find the
    gh> true IP address.

    The IP address should be logged in the first place. The domain name that it
    maps to should be merely an optional addendum to that. Any server that logs
    only the domain name is not providing useful trace information, because (given
    the fact that, as explained several times already, the address->name and
    name->address mappings are not inverses) there's no way for an administrator
    to turn the domain name into the original IP address that the service client
    used.

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

    In article <40191129.D86CC87E@Tesco.NET>,
    Jonathan de Boyne Pollard wrote:

    > gh> Even without that, many anonymous ftp servers and ssh
    > gh> servers do it.
    >
    > And they do so (although I suspect that they don't -- SSH servers _certainly_
    > have no need for such erroneous "security" measures) based upon an incorrect
    > model of the DNS.


    If you have an access list that says "allow *.", you need to do
    an address->name->address consistency check. Otherwise, anyone who
    controls their own reverse DNS could put in a PTR record that maps their
    address to something., and it would pass this check. That's the
    reason why things like SSH servers are likely to perform the consistency
    check.

    Most of the anonymous FTP servers that do it have it as part of a
    geographic heuristic. They want to limit access to US organizations,
    and they often do it by performing a reverse lookup, then performing a
    WHOIS lookup of the domain. As above, you need to perform the
    consistency check to make sure the domain they get back is valid.

    > The IP address should be logged in the first place. The domain name that it
    > maps to should be merely an optional addendum to that. Any server that logs
    > only the domain name is not providing useful trace information, because (given
    > the fact that, as explained several times already, the address->name and
    > name->address mappings are not inverses)


    If they perform a consistency check before logging, they know whether
    that mapping is invertable. If they aren't, the address should be
    logged and the name should be marked as questionable (just as sendmail
    does in "Received" lines).

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

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