"Nintendo"('s NSes) are asking my IP for it's rdns

Kevin Darcy kcd at chrysler.com
Wed Jul 25 22:13:48 UTC 2012


I'm assuming this "greatunwashed" view has recursion turned off, right?

If so, then the following approaches come to mind:
a) create a master zone for 5.37.58.216.in-addr.arpa in the 
non-recursive view, putting the PTR record at the apex
b) become a "stealth" (unpublished) slave for 5.37.58.216.in-addr.arpa 
(or its closest-enclosing zone) in the non-recursive view. Your ISP 
would need to permit zone transfers to make this approach work
c) define a new view with "match-recursive-only" and lock it down so 
that queries from external address ranges are only allowed for 
5.37.58.216.in-addr.arpa (or its closest-enclosing zone), which you 
would define as "type stub" or "type forward" in that view. Of course, 
this method will only work if these Nintendo queries are actually RD=1 
(have you verified this?). As a precaution, you might want to 
double-check your query logs (or a packet capture) and see if any of the 
queries currently being answered successfully from your 
non-authoritative view are actually -- and superfluously -- RD=1. If 
this is the case, you'll have to either fix the clients, or define the 
relevant authoritative zones in *both* views in order to keep those 
clients from breaking.

In other words, for approach (c), you might have:

/* our clients, allow to recurse */
view "internal_clients" {
     match-clients { x.x.x/24; }; /* or match-destinations, depending on 
your setup */
     recursion yes;
     ...
     /* implicit or explicit hints file, forwarders, whatever */
    ....
}

/* match only external RD=1 queries, deny everything except some 
specific zone(s) */
view "slightly_washed_Nintendoids" {
     match-recursive-only yes;
     recursion yes;
     allow-query { none; };

     zone "37.58.216.in-addr.arpa" {
         type stub;
         file "37.58.216.in-addr.arpa";
         allow-query { any; }; /* override view default */
         masters { y.y.y.y; }; /* ISP's nameservers */
     };

     ...
     /* might need some authoritative-zone definitions here, if you have 
misconfigured clients */
    ...
};

/* match external RD=0 queries, answer from authoritative data only */
view "greatunwashed" {
     recursion no;
     /* allow-query-cache { any; }; /* if you prefer to return upwards 
referrals rather than REFUSED for queries outside of authoritative data */

     ...
     /* authoritative-zone definitions here */
    ...
};

                                                 - Kevin

On 7/24/2012 7:05 AM, Brian J. Murrell wrote:
> I've come across something interesting in my named logs:
>
> 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied
> 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied
> 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied
> 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied
> 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied
> 00:16:38 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied
>
> where 216.58.37.216 is my IP address, assigned by my ISP and reverse
> resolved by my ISP's name servers.
>
> What is interesting is the fact that 205.166.76.12 are asking me
> (216.58.37.216) for the PTR for my address.
>
> Is this just broken NS software or are they (Nintendo, FWIW) doing
> something interesting, like giving everyone an opportunity to provide
> an rdns for their own IP address without everyone having to make
> classless in-addr.arpa delegation arrangements with their ISP (which
> mine refused to do)?
>
> It's kind of a neat concept if it's not just an accident of broken NS
> software.
>
> Has anyone else seen anything like this before?  Is there some
> (proposed even) standard for doing this that I'm not aware of?
>
> In any case, now to the BIND part.  It seems reasonable for me to
> answer that query, either with my own data or simply by allowing
> that query to recurse.
>
> I suppose I could create a zone for it and put some data in it for
> that one record if I wanted to provide my own data.  But what if I
> just wanted to allow recursive queries on that name so that I simply
> returned whatever the proper NSes for it reports?  I guess I could add
> a zone record for it with a forwarder(s) configured to the name's proper
> NSes, yes?  But that means me having to maintain those forward records
> in tandem with my ISP playing musical NSes (which I don't expect but
> why create a possible maintenance headache).
>
> So how could I configure BIND to allow a query for 5.37.58.216.in-
> addr.arpa to be recursive for everyone, but of course, continue to
> disallow general open recursive querying for names not served here?
>
> Cheers,
> b.
>
>
>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120725/e27aeee6/attachment.html>


More information about the bind-users mailing list