[lug] Re: Virtual Hosting

[Atkinson, Chip]

There are (or were) also public ftp servers that do a reverse lookup on the
domain and if they didn't match you couldn't get in.  I don't know if that's
the case anymore due to the prevalence of dynamic IPs these days.

Chip

> -----Original Message-----
> From: Justin [mailto:glow at jackmoves.com]
> Sent: Wednesday, March 14, 2001 6:00 PM
> To: lug at lug.boulder.co.us
> Subject: Re: [lug] Re: Virtual Hosting
> 
> 
> Say one of those records is like a mail server or something. 
> Shouldn't 
> you have the ip resolve back to the mail server hostname? I know BIND 
> will complain about MX address's that are CNAME's and not actual A 
> records for the zone. The dns resolution will still work 
> properly, but 
> I think having the PTR for the mail server hostname is the "correct" 
> way to do things. Or another example that I have experienced setting 
> up , is in the case of irc virtual hosts. The hostname needs to be a 
> PTR record otherwise it won't work.
> 
> Justin
> 
> > The alternative is not to have any reverse records (PTR) at all.
> > 
> > Nate
> > 
> > Quoting John Hernandez <John.Hernandez at noaa.gov>:
> > 
> > > Given our hypothetical scenario (where there is not a 1-to-1 
> mapping of
> > > name-to-address, rather a many-to-1 mapping), you're basically 
> forced to
> > > pick one of those names for reverse lookup purposes, aren't you?  
> What
> > > would be the alternative?
> > > 
> > > A typical client app provides an IP address to the server upon
> > > connection (in the form of an IP source address).  The order of 
> lookups
> > > (for a paranoid server) is then address -> name, and then 
> resulting-
> name
> > > -> address, not the other way around as you suggested.  
> Servers are
> > > generally happy when address(in) == address(out), as you correctly
> > > stated, but that condition is satisfied by setting your PTR RR 
> value to
> > > any one of the set of valid A RR keys.
> > > 
> > > rm at mamma.varadinet.de wrote:
> > > > 
> > > > On Wed, Mar 14, 2001 at 12:18:05PM -0700, John Hernandez wrote:
> > > > > For the purpose of reverse DNS lookup, you can generally pick 
> any of
> > > the valid A RR keys for a particular IP address.  As long as a 
> reverse
> > > -> forward lookup yields a result (IP address) equivalent to your
> > > initial input, services configured to be paranoid should be 
> satisfied.
> > > > 
> > > > I would actually advise _against_ picking any A records for 
> setting
> > > > up reverse lookups. Some services get really upset if 
> the reverse
> > > > lookup yields strange results (esp. if they do double lookup for
> > > > security reasons name->address and then address->name. If the 
> address
> > > > that comes out at the end doens't match the initial one 
> you might
> > > > have a problem). Most of the java VMs embedded in browsers will
> > > > only allow an applet to request an URL if the host part of the
> > > > URL is the same as the hopst part of the applets URL. It's easy
> > > > to imagine what happens when a cautious security manager starts
> > > > interacting with strange reverse lookups.
> > > > 
> > > >  Ralf
> > > > 
> > > > >
> > > > > -John
> > > > >
> > > > > Justin wrote:
> > > > > >
> > > > > > In BIND 8.2.x the only file that relates to what you're 
> talking
> > > about
> > > > > > is your reverse zone file. It's the file that maps the ip's 
> back
> > > to
> > > > > > specific A record host names. As far as virtual hosting I 
> don't
> > > believe
> > > > > > you can have a file like this for virtual use. After all, 
> virtual
> > > hosts
> > > > > > don't really have their own ip address, they map back to 
> another
> > > > > > machines A record ip address. Which, in turn, that 
> ip address 
> must
> > > > > > reverse lookup to it's respective host as defined by that A
> > > record. I
> > > > > > think this stuff is in a BIND RFC somewhere, but 
> I'm sure. I 
> also
> > > may
> > > > > > be way off here, but this has been my understanding since I 
> can
> > > > > > remember...
> > > > > >
> > > > > > Justin
> > > > > >
> > > > > > > It was my understanding that all the virtual hosts are 
> listed in
> > > one
> > > > > > > file and that file is pointed back to the server 
> IP.  Maybe 
> it
> > > > > > > involves the $INCLUDE directive?
> > > > > > >
> > > > > > > Note: When you reply to this message, please include the 
> mailing
> > > > > > >       list/newsgroup address in Cc: and my email 
> address in 
> To:.
> > > > > > >
> > > > > > >
> > > 
> *********************************************************************
> > > > > > > Signed,
> > > > > > > SoloCDM
> > > > > > > _______________________________________________
> > > > > > > Web Page:  http://lug.boulder.co.us
> > > > > > > Mailing List:
> > > http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > -----
> > > > > > glow at jackmoves.com
> > > > > > www.jackmoves.com
> > > > > > _______________________________________________
> > > > > > Web Page:  http://lug.boulder.co.us
> > > > > > Mailing List: 
> http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > > > _______________________________________________
> > > > > Web Page:  http://lug.boulder.co.us
> > > > > Mailing List: 
> http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > > _______________________________________________
> > > > Web Page:  http://lug.boulder.co.us
> > > > Mailing List: 
http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > 
> 
> 
> 
> --
> Nate Duehr, nate at natetech.com
> 
> "Never underestimate the bandwidth of a 747 filled with CD-ROM's."
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 
> 

-----
glow at jackmoves.com
www.jackmoves.com
_______________________________________________
Web Page:  http://lug.boulder.co.us
Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug