[lug] Re: Virtual Hosting

[Justin]

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