On Sun, 2007-06-24 at 18:30 -0700, Marc Perkel wrote:
>
> Eli wrote:
> >> Maybe I'm missing something. Can I take one of my IP addresses and make
> >> the RDNS appear to be from xxx.amd.com and make a lookup on xxx.amd.com
> >> agree?
> >
> > Yes you can. That's why reverse DNS information is pretty much completely
> > useless when doing any type of tracing. I suggest you read up on DNS
> > servers and how zonefiles work et al before going too far on speculations
> > regarding DNS, especially if you're using the results to filter stuff (email
> > in this case).
> >
> If you do a reverse lookup and then check to see if the name resolves to
> the IP that you looked up you can tell it's fake.
That tells nothing of the sort, despite the advise that forward and
reverse entries /should/ match. (It's really only a /must/ for
authoritative DNS servers.) There's many reasons why there may not be
a match, temporarily or permanently:
Consider a failover solution, for example. Normally, it would be:
# Using a private address space here, as it's an example.
# In real life, it would be in a public address space.
zone 16.16.172.in-addr.arpa:
1 IN PTR foo.my.example.
2 IN PTR bar.my.example.
zone my.example:
foo IN A 172.16.16.1
bar IN A 172.16.16.2
But, if foo goes down, the forward zone changes to:
foo IN A 172.16.16.2
bar IN A 172.16.16.2
Or this example, with a multi-homed host:
zone my.example:
foo IN A 172.17.17.1
...
zone 17.17.172.in-addr.arpa:
1 IN PTR foo.my.example.
2 IN PTR foo.my.example.
Where some of the traffic goes out from 172.17.17.1 and some from .2,
depending on routing. If you look up 172.17.17.2, you get
foo.my.example, but if you look up foo.my.example, you get 172.17.17.1.
This is perfectly legal.
Regards,
--
*Art
