looking up rr.com associated ptr and a records (problem?)
atatat at atatdot.net
Sun Sep 30 20:53:17 UTC 2001
>>>But it's not actually as bad as it looks -- they just have different
>>>names for the same hosts (and one missing one in this case):
>>> $ host -a nycdns1.nyc.rr.com
>>> nycdns1.nyc.rr.com A 184.108.40.206
>>> $ host -a nycdns1fa.rdc-nyc.rr.com
>>> nycdns1fa.rdc-nyc.rr.com A 220.127.116.11
>>> $ host -a nycdns2.nyc.rr.com
>>> nycdns2.nyc.rr.com A 18.104.22.168
>>> $ host -a nycdns2fa.rdc-nyc.rr.com
>>> nycdns2fa.rdc-nyc.rr.com A 22.214.171.124
>> i noted that. i thought it looked like a dropped project to cut over
>> dns server names.
> The DNS delegates by name, not by IP address. If the IP address
>changes, that doesn't change the delegation. If the names mis-match,
>then that's messed up delegation information.
i meant "dropped" meaning the the upper set had been changed but not
the lower set. or vice versa. who knows?
>>>They do have some semi-serious problems with reverse is-matches for the
>>>$ host -A nycdns1.nyc.rr.com
>>> !!! nycdns1.nyc.rr.com address 126.96.36.199 maps to nycdns1fa.rdc-nyc.rr.com
>>>$ host -A nycdns2.nyc.rr.com
>>> !!! nycdns2.nyc.rr.com address 188.8.131.52 maps to nycdns2fa.rdc-nyc.rr.com
>>>but it's not even serious enough to trip the TCP Wrappers "paranoid" check.
>> right. my named, on the other hand, doesn't like it for some reason.
> See above. If you're going to be running nameservers, then their
>reverse DNS should match. Above all other machines on the Internet,
>the reverse DNS for nameservers should match.
um...the requirement for a valid a record i can see, but dns doesn't
rely on names mapping back to addresses, does it? or are you
referring only to human debugging capabilities and needs?
|-----< "CODE WARRIOR" >-----|
codewarrior at daemon.org * "ah! i see you have the internet
twofsonet at graffiti.com (Andrew Brown) that goes *ping*!"
andrew at crossbar.com * "information is power -- share the wealth."
More information about the bind-workers