"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