Odd result for a redeleageted domain

[Kevin Darcy]

Simon Dodd wrote:
> I have what seems like an odd issue. It's something of a moot point in that 
> I'm pretty sure that whatever the issue is, it's on the authoritative side 
> (which we don't control), but a customer brought it to us, it's a little odd 
> and I'd like to understand what's going on.
>
> The authoritative name servers for thereddress.com at the parent zone are 
> ns1.buyhttp.com and ns2.buyhttp.com. The "correct" IP for 
> www.thereddresser.com is 67.18.164.50. If I look up that record directly at 
> the listed name servers that's the IP I get back:
>
>     [simon at linux1 simon]$ dig www.thereddresser.com @ns1.buyhttp.com +short 
> thereddresser.com.
>     67.18.164.50
>     [simon at linux1 simon]$ dig www.thereddresser.com @ns2.buyhttp.com +short 
> thereddresser.com.
>     67.18.164.50
>
> If I run a DNS report on the domain name, 
> http://www.dnsstuff.com/tools/dnsreport.ch?domain=thereddresser.com, it 
> reports that although the authoritative name servers for thereddress.com at 
> the parent zone are ns1.buyhttp.com and ns2.buyhttp.com, the NS records at 
> the nameservers are ns1.mosmenu.com and ns2.mosmenu.com.
>
> If I look the domain up on our recursors (all four run BIND 9) they get 
> back:
>
>     % dig www.thereddresser.com +trace
>
>     <<snip>>
>
>     ;; ANSWER SECTION:
>     www.thereddresser.com.  47m38s IN A     8.15.231.100
>
>     ;; AUTHORITY SECTION:
>     thereddresser.com.      1h27m43s IN NS  ns1.mosmenu.com.
>     thereddresser.com.      1h27m43s IN NS  ns2.mosmenu.com.
>
>     ;; ADDITIONAL SECTION:
>     ns1.mosmenu.com.        1d5h20m2s IN A  8.15.231.100
>     ns2.mosmenu.com.        1d5h20m2s IN A  8.15.231.100
>
> Which, of course, is the wrong IP. Apparently - take with a pinch of salt - 
> this is working for customers of other ISPs than mine. Nevertheless, 
> querying Verizon's name servers, I see that they get the right answer:
>
>     [simon at linux1 simon]$ dig www.thereddresser.com @4.2.2.1 +short 
> thereddresser.com.
>     67.18.164.50
>     [simon at linux1 simon]$ dig www.thereddresser.com @4.2.2.2 +short 
> thereddresser.com.
>     67.18.164.50
>
> Ours don't:
>
>     [simon at linux1 simon]$ dig www.thereddresser.com @12.109.94.4 +short 
> 8.15.231.100
>     [simon at linux1 simon]$ dig www.thereddresser.com @12.109.94.5 +short 
> 8.15.231.100
>
> Another customer today brought an identical problem to me with the domain 
> fccparis.org, which has an identical DNS setup - BuyHTTP redelgated to 
> MosMenu. So what would be causing this? Seemingly, the ns1.buyhttp.com 
> provide one answer but also delegate to the other pair, each providing 
> different answers. The closest that I can understand would be that if the 
> auth provider is running bind, the zone file at ns1 and 2.buyhttp.com would 
> be something like this:
>
>     @        IN     NS  ns1.mosmenu.com.
>     @        IN     NS  ns2.mosmenu.com.
>     @        IN     A  67.18.164.50
>     www    IN     CNAME  @
>
> Are my name servers broken because they're querying the "mosmenu" pair (and 
> if not, why aren't verizons) or is their (BuyHTTP's) config completely 
> screwy - and if the latter (out of curiosity) how and why would you create 
> such a result?
Looks like they tried to repoint the domain away from the evil, 
braindead nameserver running at 8.15.231.100, by changing the 
delegations to ns1.buyhttp.com and ns2.buyhttp.com. But what they forgot 
to change was the NS records at the apex of the zone. So, after the 
initial (correct) A-record is fetched, used, and expires, 
standards-conforming resolvers, which give precedence to the apex NS 
records over the delegation NS records (see RFC 2181) will try to 
resolve any new www.thereddresser.com queries from ns{1,2}.mosmenu.com, 
which includes the evil 8.15.231.100 as ns1, and an unreachable (at 
least from here) device at 64.74.223.6 as ns2 (note that this resolution 
of ns2.mosmenu.com is different from what you show above, so I'm 
assuming it's changed recently). The resolver will keep getting the 
wrong answer until the thereddresser.com NS records expire, at which 
time they'll go back up to the .com servers again, get the right answer 
from the "buyhttp" nameservers, use it for a while, and the cycle will 
repeat all over again.

                                                                         
                  - Kevin