looking up rr.com associated ptr and a records (problem?)
atatat at atatdot.net
Sun Sep 30 18:44:55 UTC 2001
>> would someone mind eyeballing the configuration that rr.com has set up
>> for name service for the ptr for 184.108.40.206 and for associated
>> zones (rr.com, nyc.rr.com, rdc-nyc.rr.com, etc)?
>Where does rdc-nyc.rr.com come into the picture? That just happens to
>be the domain some of the nameservers are in.
i also happen to have problems with it, but only by its association
with the 76.108.66.in-addr.arpa and nyc.rr.com zones.
>> i'm not sure that i can see anything wrong (outside of the delegations
>> not matching at the zone cuts),
>Yeah -- their inside and outside NS records don't always match:
> $ host -r -t ns 76.108.66.in-addr.arpa DNS1.RR.COM
> 76.108.66.in-addr.arpa NS nycdns2fa.rdc-nyc.rr.com
> 76.108.66.in-addr.arpa NS ns1.rdc-nyc.rr.com
> 76.108.66.in-addr.arpa NS nycdns1fa.rdc-nyc.rr.com
> $ host -r -t ns 76.108.66.in-addr.arpa ns1.rdc-nyc.rr.com
> 76.108.66.in-addr.arpa NS nycdns2.nyc.rr.com
> 76.108.66.in-addr.arpa NS nycdns1.nyc.rr.com
...which is silly, but not quite terrible since the one that doesn't
list itself still responds authoritatively.
>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 220.127.116.11
> $ host -a nycdns1fa.rdc-nyc.rr.com
> nycdns1fa.rdc-nyc.rr.com A 18.104.22.168
> $ host -a nycdns2.nyc.rr.com
> nycdns2.nyc.rr.com A 22.214.171.124
> $ host -a nycdns2fa.rdc-nyc.rr.com
> nycdns2fa.rdc-nyc.rr.com A 126.96.36.199
i noted that. i thought it looked like a dropped project to cut over
dns server names.
>They do have some semi-serious problems with reverse is-matches for the
>$ host -A nycdns1.nyc.rr.com
> !!! nycdns1.nyc.rr.com address 188.8.131.52 maps to nycdns1fa.rdc-nyc.rr.com
>$ host -A nycdns2.nyc.rr.com
> !!! nycdns2.nyc.rr.com address 184.108.40.206 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.
>All else seems OK though (and in particular within the zones for the
>example you give their forward and reverse names all match and all exist
>so far as I can see).
yeah. i got that. they've apparently got the data, but in the wrong
>> but my 8.3.0-t1a server only returns
>> servfail for the ptr record and for any stuff under nyc.rr.com or
>no problems here with 8.2.3-REL.... :-)
you should be using 8.2.4-REL :P
>> i don't know if it's a bug (maybe too much paranoia
>> about glue a records?)
>> or just admin incompetence on the part of
>> rr.com (not impossible).
>well it works OK for 8.2.3 and you can never expect NS records to be
>100% consistent between delegations and internal declarations (and
>indeed sometimes the differences are what make it possible to stumble
>along with mostly-operational status while delegations get repaired).
that i knew, though i usually try to make the bottom cut over at the
same time the top cuts over, and make the old bottom servers just
return the new bottom servers.
>> the eyeballing i've done was via dig and walking the dns delegations
>> down from the root by hand.
>"host" is my friend! ;-)
i know, but dig is mine. host still uses the search path from the
resolv.conf. dig does not. :-)
|-----< "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