|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: AOL rejecting mail from IP's w/o reverse DNS ?
Adam McKenna wrote:
>
> On Thu, Dec 04, 2003 at 02:04:54PM -0800, Crist Clark wrote:
> > $ dig 3.2.1.in-addr.arpa soa
> > $ dig 42.3.2.1.in-addr.arpa soa
>
> This email contains approximately the same information as Randy's did. Yes,
> the SOA's will be different. That is what is intended. The nameserver that
> is authoritative for 3.2.1.in-addr.arpa is delegating 42.3.2.1.in-addr.arpa
> to 5.6.7.86. Were you trying to make some other point or just showcasing
> your 'dig' skills?
Sorry, I was not clear. I was looking at the examples on the webpage that
was pointed to previously. The pain killers for my injured foot have made
me a bit fuzzy today. You could set things up to look a little less broken
than in his examples. I guess you can get around,
$ dig @<isp-server> 3.2.1.in-addr.arpa soa
$ dig @<your-server> 3.2.1.in-addr.arpa soa
Breaking your own server, by setting up a zone for each IP address. Not
pretty.
You have in-addr.arpa domains with A records. Uck.
It's based on a strange premise. From that web page,
The fundamental mistake made by the authors of RFC 2317 is that it
didn't occur to them that a delegation from a superdomain's content
DNS servers does not have to point to the apices of the "zones" in
the subdomain's content DNS servers. Or, put another way, it is not
necessary for the apex of a "zone" to be a domain that the rest of
the world considers to be within the content DNS server's bailiwick.
Whereas I think the "mistake" they made seems to be that they follow
RFC1034,
- NAME SERVERS are server programs which hold information about
the domain tree's structure and set information.
...
... Name servers
know the parts of the domain tree for which they have complete
information; a name server is said to be an AUTHORITY for
these parts of the name space. Authoritative information is
organized into units called ZONEs, and these zones can be
automatically distributed to the name servers which provide
redundant service for the data in a zone.
All of that aside, I don't see how it is any easier than RFC2317. In
fact you double the number of records when you add additional nameservers
to your zone (which isn't really a zone). To quote one of his examples,
I don't see how getting your ISP to do,
$ORIGIN 168.50.204.in-addr.arpa.
$GENERATE 0-15 $ NS a.ns.$
$GENERATE 0-15 a.ns.$ A 204.50.168.2
Is any harder than,
$ORIGIN 168.50.204.in-addr.arpa.
$GENERATE 0-15 CNAME $.0/28
0/28 NS ns.mydomain.org.
--
Crist J. Clark [email protected]
Globalstar Communications (408) 933-4387
The information contained in this e-mail message is confidential,
intended only for the use of the individual or entity named above.
If the reader of this e-mail is not the intended recipient, or the
employee or agent responsible to deliver it to the intended recipient,
you are hereby notified that any review, dissemination, distribution or
copying of this communication is strictly prohibited. If you have
received this e-mail in error, please contact [email protected]
|