On Mon, 2006-06-26 at 07:38 -0400, Thomas E Dukes wrote: > > > -----Original Message----- > > From: centos-bounces at centos.org > > [mailto:centos-bounces at centos.org] On Behalf Of Johnny Hughes > > Sent: Monday, June 26, 2006 7:19 AM > > To: CentOS ML > > Subject: RE: [CentOS] Re: DNS Server > > > > On Sun, 2006-06-25 at 20:32 -0400, Thomas E Dukes wrote: > > <snip> > > > > > > > > So even if a service such as zoneedit, say they can do > > reverse DNS, it > > > won't work? > > > > > > I really don't understand how it can work in one direction > > and not the > > > reverse. If they can keep up with my IP address and match it to my > > > domainanme, seems they could do the reverse. > > > > > > > OK ... rather than you staying confused on this issue, I will > > try to explain it in basic terms. > > > > DNS converts names to IPs (forward lookups) and IPs to names > > (reverse lookups). > > > > A forward lookup is when you have a name (www.abcxyz.com) and > > need a number. This this case, there is a domain owner and > > that domain has it's own DNS Zone. The owner of that Zone > > can put whatever IP addresses > > (numbers) with names that they want in that zone. > > > > In the case of a forward lookup, there is no predefined zone > > at all ... > > you can have as many names as you want, and since people pay > > for it (the name), it stands to reason that will keep it > > updated properly. > > > > A reverse lookup is different. The standard for reverse > > lookups break them down in "Class C" blocks (that is, the > > first 3 groups of numbers are the network number, the last > > group is the host number). If you have an ip address of: > > > > 192.87.99.234 > > > > The network number is 192.87.99.0, the subnet mask is > > 255.255.255.0, the host number is 234, and the reverse lookup > > domain is: > > > > 99.87.192.in-addr.arpa > > > > All 254 host addresses in that zone are normally assigned > > from the owner of that zone from one machine. If someone > > buys the whole class C network, they get to control the zone, > > otherwise it is normally controlled by the ISP that owns all the IPs. > > > > It is possible, but not usually done, to break up the reverse > > into smaller ranges. > > > > Tom Diehl has already mentioned RFC 2317: > > > > http://www.faqs.org/rfcs/rfc2317.html > > > > Using the techniques there, an ISP _CAN_ transfer control of > > some reverse lookup domains. They will normally not do it > > unless you have a fairly large network, however. > > > > I hope this helps you understand that forward zones are > > designed to easily break them down into 1 or 2 names ... but > > reverse zones are predefined and not designed for less than 1 > > class C network blocks. > > Hello Johnny, > > I guess that makes sense. It seems it would create too much work for the > ISP to handle the reverse lookup for a single IP. If they dole them out > that way, they should either do it or delegate them. > > All this is to operate a mail server without bounces. Is this why it > recommedned to use your ISP's mail server as smarthost? Does this mean I > would be using the ISP's mail server for outgoing mail? Or is it just > 'stamped' with the ISP's name to prevent bounces? > > Thanks, > > Eddie Most ISPs block outbound port 25 traffic now ... only allowing mail server operation (or even normal sending of e-mail via a client) to be done out of their mail servers. I had, for many years, run a mail server on my linux box at home. Spammers (and viruses) have ruined that option for us. I now have a domain that I use for e-mail at a hosting provider, as too many servers now block dynamic ranges and cable/dsl ranges to combat spam. I have since just setup an NX desktop and use that to get to my mail at my home desktop when I am not there ... which seems to work OK. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060626/fb5c5b84/attachment-0004.sig>