🚀 go-pugleaf

Ian Michael (ian.michael@impub.demon.co.uk) wrote:
: We are using .htaccess to restrict access to certain directories on our
: site on New Commweb. Recently, we have had a few complaints that people
: who previously had been able to access the directories no longer can. It
: appears that these are all where we have entered the domain name (rather
: than the IP address) into the .htaccess file.

: Has anything changed that might have caused this?

Presumably you're using the "Allow from..." directive? If you put a
domain name in, then the Apache server will do a reverse DNS lookup on
the IP address supplied by the client, then match it against the
specified domain. Maybe DNS lookups on the server are not working, or
are failing for those particular clients.

How about, for those clients for whom it's failing, doing a reverse DNS
lookup yourself on their IP addresses using Demon's name servers, e.g.

    nslookup a.b.c.d 158.152.1.58

and seeing if reverse DNS works?

Andrew.
-- 
Andrew Haylett                      Tel. +44 1763 852222 Fax. +44 1763 853324
Software Engineer, Webmaster        Email: ajh@primagraphics.co.uk
Primagraphics, Nr. Cambridge, UK    Web: http://www.primagraphics.co.uk/

In article <9591sq$hb3$1@atlas.primag>, Andrew Haylett
<ajh@primag.co.uk> writes
>Ian Michael (ian.michael@impub.demon.co.uk) wrote:
>: We are using .htaccess to restrict access to certain directories on our
>: site on New Commweb. Recently, we have had a few complaints that people
>: who previously had been able to access the directories no longer can. It
>: appears that these are all where we have entered the domain name (rather
>: than the IP address) into the .htaccess file.
>
>Presumably you're using the "Allow from..." directive? If you put a
>domain name in, then the Apache server will do a reverse DNS lookup on
>the IP address supplied by the client, then match it against the
>specified domain. Maybe DNS lookups on the server are not working, or
>are failing for those particular clients.
>
Yes, we are using allow from.

>How about, for those clients for whom it's failing, doing a reverse DNS
>lookup yourself on their IP addresses using Demon's name servers, e.g.
>
>    nslookup a.b.c.d 158.152.1.58
>
>and seeing if reverse DNS works?

Help, excuse my ignorance; where from? nslookup is not allowed from
telnetting to the web server (not much is). Using Demon's network tools,
I can get an IP address for one of the "problem" domains, so presumably
the reverse DNS is working.

However, another (which is a Demon SDU) was not working yesterday, but
is today!! Aaargh.

-- 
Ian Michael
NIR Publications                                          Publishers of:
6 Charlton Mill                    Journal of Near Infrared Spectroscopy
Charlton                                                        NIR news
Chichester                         
West Sussex PO18 0HY                                Training Courses in:
United Kingdom                                Near Infrared Spectroscopy
Tel: +44-1243-811334                                        Chemometrics
Fax: +44-1243-811711                                        
E-mail: ian.michael@nirpublications.com
Web site: http://www.nirpublications.com

In article <VHJk4AEc1De6EACu@impub.demon.co.uk>
           ian.michael@impub.co.uk "Ian Michael" writes:

> In article <9591sq$hb3$1@atlas.primag>, Andrew Haylett
> <ajh@primag.co.uk> writes
> 
> >How about, for those clients for whom it's failing, doing a reverse DNS
> >lookup yourself on their IP addresses using Demon's name servers, e.g.
> >
> >    nslookup a.b.c.d 158.152.1.58
> >
> >and seeing if reverse DNS works?
> 
> Help, excuse my ignorance; where from? nslookup is not allowed from
> telnetting to the web server (not much is). Using Demon's network tools,
> I can get an IP address for one of the "problem" domains, so presumably
> the reverse DNS is working.

You don't need to telnet into the web server; issue the nslookup command
on your own machine.  Look at the suggested command above: when nslookup
is given two parameters, it takes the second one as telling it which name
server to use to look up the first parameter.  (If you have a lot to look
up, then you can put a minus sign in the place of the first parameters,
and thereby gain an interactive session with the nameserver specified by
the second: note that under these circumstances, you'll have to look up
PTR records explicitly, and reorder a.b.c.d into d.b.c.a.in-addr.arpa.)

-- 
Brian {Hamilton Kelly}                                          bhk@dsl.co.uk
    "We have gone from a world of concentrated knowledge and wisdom to one of
    distributed ignorance.  And we know and understand less while being incr-
    easingly capable."                          Prof. Peter Cochrane, BT Labs

Ian Michael (ian.michael@impub.demon.co.uk) wrote:

: >How about, for those clients for whom it's failing, doing a reverse DNS
: >lookup yourself on their IP addresses using Demon's name servers, e.g.
: >
: >    nslookup a.b.c.d 158.152.1.58
: >
: >and seeing if reverse DNS works?

: Help, excuse my ignorance; where from? nslookup is not allowed from
: telnetting to the web server (not much is). Using Demon's network tools,
: I can get an IP address for one of the "problem" domains, so presumably
: the reverse DNS is working.

Well, resolving domain names to IP is "normal" DNS, not reverse; I'm
not enough of a DNS guru to know whether one could work and not the
other. I'm willing to try out a few for you if you like.

As far as nslookup is concerned, you do that on your machine, not on
Demon's (although you can run a CGI script on their servers, which do
allow nslookup). If you're on Windows, presumably one can get nslookup
for Windows...?

: However, another (which is a Demon SDU) was not working yesterday, but
: is today!! Aaargh.

Have you considered a different approach, namely using password or
cookie based authentication rather than by address? Might be rather
more reliable. Your address-based approach might be not very flexible,
e.g. for people coming in through proxy caches or whatever.

--
Andrew Haylett                      Tel. +44 1763 852222 Fax. +44 1763 853324
Software Engineer, Webmaster        Email: ajh@primagraphics.co.uk
Primagraphics, Nr. Cambridge, UK    Web: http://www.primagraphics.co.uk/