looking up rr.com associated ptr and a records (problem?)

Andrew Brown 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 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
>	$ host -a nycdns1fa.rdc-nyc.rr.com
>	nycdns1fa.rdc-nyc.rr.com        A
>	$ host -a nycdns2.nyc.rr.com 
>	nycdns2.nyc.rr.com      A
>	$ host -a nycdns2fa.rdc-nyc.rr.com 
>	nycdns2fa.rdc-nyc.rr.com        A

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
>NS hostnames:
>$ host -A nycdns1.nyc.rr.com 
> !!! nycdns1.nyc.rr.com address maps to nycdns1fa.rdc-nyc.rr.com
>$ host -A nycdns2.nyc.rr.com 
> !!! nycdns2.nyc.rr.com address 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
place slightly.

>> but my 8.3.0-t1a server only returns
>> servfail for the ptr record and for any stuff under nyc.rr.com or
>> rdc-nyc.rr.com.
>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 mailing list