A client of mine just discovered that he could no longer do ftp
transfers to my machine. His IP address had changed to one in
12.240.20 and there is no reverse DNS for that block. His
previous assignment was in a totally different block which did
have reverse DNS. Calls to ATTBI got the answer that they
are not obligated to provide reverse DNS and have no plans to
do so. My servers refuse connections when there is no reverse
lookup.
Is this common?
yes, i've had similar problems with cox both when i had cox@work business service, and now that i have cox@home residential service.
this feeds right into the thread that branched off my post about "network diameter" in which people are talking about "clue factor". these networks spring up overnight, built by people who are missing some of the fundamental knowledge about how all this "stuff" works. and we're stuck with it as end users.
-b
A client of mine just discovered that he could no longer do ftp
transfers to my machine. His IP address had changed to one in
12.240.20 and there is no reverse DNS for that block. His
previous assignment was in a totally different block which did
have reverse DNS. Calls to ATTBI got the answer that they
are not obligated to provide reverse DNS and have no plans to
do so. My servers refuse connections when there is no reverse
lookup.
Your server is using this INADDR lookup for what purpose? Security?
INADDR is a really good idea for network operators to be using, and a really BAD idea for server operators to use as a security mechanism. Fix your server to be less anal.
read draft-ietf-dnsop-inaddr-required-03.txt from your favorite Internet Drafts archive for additional information on this subject.
Is this common?
I have a CDPD card which has a fixed address. It's from Verizon Wireless. There's no INADDR. There seems to be a lack of understanding and clue all around on INADDR, which is the motivation for the above-mentioned draft. Having something to point network operators and server operators to would, IMO, help.
--
I suppose I could set up a bogus reverse for him, but, feh...
Either you set up something, or you can make your server not care about reverse, or lose the customer.
[ On Tuesday, June 18, 2002 at 14:51:16 (-0400), Daniel Senie wrote: ]
Subject: Re: ATTBI refuses to do reverse DNS?
INADDR is a really good idea for network operators to be using, and a
really BAD idea for server operators to use as a security mechanism. Fix
your server to be less anal.
Excuse me? It's _still_ all the security an Internet DNS client has!
When a hostname is important, for whatever reasons, an application MUST
confirm the consistency of forward and reverse DNS.
read draft-ietf-dnsop-inaddr-required-03.txt from your favorite Internet
Drafts archive for additional information on this subject.
According to my reading everything in _your_ draft strongly suggests
that IN-ADDR records be fully and properly populated, despite at the
same time warning that applications should not "rely" on consistency
checks of the forward and reverse DNS as a security check.
Unfortunately this most recent revision of your draft contains a
significant and "dangerous" flaw -- it confuses application security
checks with DNS consistency checks. Indeed applications should not use
the DNS for authentication or for authorisation. However if any trust
is put in the hostname used by a client, for any purpose whatsoever,
(for audit logs, etc.) then full consistency checks of the DNS for that
hostname _MUST_ be done! DNS spoofing, even just by accident, is just
too easy and too common (and yes, it really does happen by accident by
way of cache pollution, still in this day and age!).
[ On Tuesday, June 18, 2002 at 14:51:16 (-0400), Daniel Senie wrote: ]
Subject: Re: ATTBI refuses to do reverse DNS?
INADDR is a really good idea for network operators to be using, and a
really BAD idea for server operators to use as a security mechanism. Fix
your server to be less anal.
Excuse me? It's _still_ all the security an Internet DNS client has!
When a hostname is important, for whatever reasons, an application MUST
confirm the consistency of forward and reverse DNS.
Absolutely. If you can't confirm the hostname forwards and backwards, don't
trust it at all. If you can confirm it both ways, you can put some small
amount of trust in it. But the difference between the value in these two
cases is very small.
Unfortunately this most recent revision of your draft contains a
significant and "dangerous" flaw -- it confuses application security
checks with DNS consistency checks. Indeed applications should not use
the DNS for authentication or for authorisation. However if any trust
is put in the hostname used by a client, for any purpose whatsoever,
(for audit logs, etc.) then full consistency checks of the DNS for that
hostname _MUST_ be done! DNS spoofing, even just by accident, is just
too easy and too common (and yes, it really does happen by accident by
way of cache pollution, still in this day and age!).
So if you can't confirm the hostname, don't trust it. Since you can't trust
it even if you can confirm it, it doesn't make much difference. If you need
the maximum security DNS can possibly give you, keep the IP, time, hostname,
and results of reverse DNS.
DS
Most providers provide some kind for forward/reverse mapping, including
ATTBI. Often, however, they do provide customized reverse mapping (ie,
myhost.mydomain.com). That may be where the disconnect.
I believe that ATTBI has a script that auto-generates forward/reverse
mappings on a regular basis. You client may be just in a waiting period
before the problem corrects itselft.
GAH! Sorry, bad typo.
Most providers provide some kind for forward/reverse mapping, including
ATTBI. Often, however, they do provide customized reverse mapping (ie,
^^ do not