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

Andrew Brown atatat at atatdot.net
Sun Sep 30 18:38:54 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)?
>	Well, a friend of mine runs at least part of the DNS for rr.com, 
>so if there are any problems, I hope that he can help clarify what's 
>going on.  I'll forward your note to him, and see if he can help.

that would be good.  i've had problems with them and their reverse dns
in the past that no one there was able to diagnose, or evern to
understand my explanation of the problem.  afaict, it only went away
when arin finally delegated the bottom half of the class b i'm in to

>	Myself, starting with doc, I don't see anything wrong with 
>rr.com, but I do note that nyc.rr.com and rdc-nyc.rr.com have lame 
>delegations with ns1.rdc-nyc.rr.com:

not lame, it just appears different from above and below.

dns[1234].rr.com all delegate nyc.rr.com and rdc-nyc.rr.com like this

    rdc-nyc.rr.com  3600 IN NS      ns1.rdc-nyc.rr.com
    rdc-nyc.rr.com  3600 IN NS      nycdns1fa.rdc-nyc.rr.com
    rdc-nyc.rr.com  3600 IN NS      nycdns2fa.rdc-nyc.rr.com

but those three servers all respond like this

    rdc-nyc.rr.com  10800 IN        NS      nycdns1fa.rdc-nyc.rr.com
    rdc-nyc.rr.com  10800 IN        NS      nycdns2fa.rdc-nyc.rr.com

even though ns1.rdc-nyc.rr.com *will* respond with aa set.

>	Looking at the 76.108.66.in-addr.arpa zone, I note that all of 
>the delegated nameservers are lame:

sort of lame, but not, in a weird way.  they don't set aa, but the
ttls don't decrement either, as you usually get with a non-auth

>	It's hard using more detailed debugging tools like dnswalk, 
>because I can't do zone transfers from their advertised nameservers. 
>However, I do happen to have a fully licensed copy of DNS Expert 
>Professional 1.6 from Men & Mice (see 
><http://www.menandmice.com/2000/2100_dns_expert.html>), so here's 
>what it sees on the various zones in question:

neat.  :)

>                               DNS Expert
>                    Detailed Report for nyc.rr.com.
>o The name server name "nycdns2fa.rdc-nyc.rr.com." in an NS record
>   contains invalid characters
>     The name server name "nycdns2fa.rdc-nyc.rr.com." in the NS record
>      for "nyc.rr.com." contains invalid characters.  Host names must
>     only contain the characters a-z, A-Z, 0-9 and a dash (-).

uh...how is "nycdns2fa.rdc-nyc.rr.com." not composed of [-a-zA-Z0-9]?
or is the program mistaking the dot for an illegal character?

>o The name server "ns1.rdc-nyc.rr.com." is only listed in delegation
>   data
>     The server "ns1.rdc-nyc.rr.com." is listed as being authoritative
>     for the zone according to the delegation data, but there is no NS
>     record for that server in the zone data.  Delegation data and
>     zone data should always match.

same thing...i knew that one.  :)


>                               DNS Expert
>              Detailed Report for 76.108.66.in-addr.arpa.
>o The name server "nycdns1fa.rdc-nyc.rr.com." is only listed in
>   delegation data
>o The name server "ns1.rdc-nyc.rr.com." is only listed in delegation
>   data
>o The name server "nycdns2.nyc.rr.com." is not listed in delegation
>   data
>o The zone contains more than one authoritative name server with the
>   same IP address

not quite a comprehensive report, nothing about the lack of aa bits on
responses, and i still have no idea why my named doesn't like them.

>>  i'm not sure that i can see anything wrong (outside of the delegations
>>  not matching at the zone cuts), 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.  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).
>	Probably because all of their delegated nameservers for at least 
>this one reverse zone are lame.

sort of lame...not entirely.  they've got data from somewhere
which...oh wait.  perhaps their data has expired, but they haven't
tossed it out?

>>  the eyeballing i've done was via dig and walking the dns delegations
>>  down from the root by hand.
>	When checking out problems with the DNS, especially delegation 
>problems, you really, really want to use automated tools.

yeah, i know, but i have a habit of walking stuff down by hand and
rolling my own tools.  the one i was working on to do this kind of
checking isn't done yet.

|-----< "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