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

[Brian J. Murrell]

On 12-07-24 07:53 AM, Phil Mayers wrote:
> On 24/07/12 12:05, Brian J. Murrell wrote:
> 
> Change ISP?

Ahhhh.  You must be one of those people who live in that part of the
world where internet service providing is not a monopoly, duopoly or at
best a price-fixing oligopoly.  :-)  Unfortunately that's not all of us.

Besides, although my ISP won't delegate the in-addr.arpa. for my one
single IP address to me, they will allow me to tell them what to put in
for it's PTR.  So it doesn't totally suck.

> I don't think that's what is going on. But even if it were, I think that
> would be a bad idea, personally.

Why?  I mean other than a knee-jerk reaction to that behavior not (yet)
being documented in an RFC somewhere?  I mean for practical purposes why
is what they are (or rather, could be, assuming my suggestion about what
they could be doing is correct) doing necessarily bad?

> DNS is well-specified in the RFCs.

Sure.  So there is no room for expansion?

> Violating those to work around lazy ISPs is not a good solution.

What exactly is it violating?  Is there somewhere in an RFC that says an
NS MUST NOT try to query a nameserver at a given IP for the PTR RR for
itself?

If we assume they are first going to an IP address to see if it's
willing to provide a PTR for itself and then falling back to using the
procedure defined in the RFCs and asking the NSes defined for that IP,
what are they breaking?  It seems to be they are "extending", not violating.

The fact that it's Nintendo which does create networkable hardware is
what makes me wonder if it's more by design than brokenness.  What if,
for example, they put a lightweight NS into all of their hardware (i.e.
handheld and other game units) that returns a PTR for it's own IP as a
means of identifying the unit?  Certainly, they could have just invented
their own "who are you" protocol, but instead they decided to do
something interesting with an existing protocol that already answers
"who is".

My son has a gameboy or 2.  It might be interesting to see if it
responds to a PTR query.  I will have to wait for him to come back from
camp to see.

> We see all kinds of weird nonsense come into our DNS servers. We see
> LOTS AND LOTS of these two zones, continually:
> 
> 75.97.111.76#27300: view main: query (cache)
> 'mx241.emailfiltering.com/A/IN' denied
> 
> 41.218.219.221#26895: view main: query (cache)
> 'service17.mimecast.com/A/IN' denied

Yeah, but these are not "interesting".  These look like either
misconfigured resolvers, or opendns probing, or something.  The thing
that makes the behavior I posted about "interesting" (IMHO) is the
possible usefulness of it.

> But we also see a trickle of other crap that is nothing to do with us,
> for example:
> 
> 190.26.0.2#16074: view main: query (cache) 'ns1.webservices.net/A/IN'
> denied
> 
> 59.90.143.134#48824: view main: query (cache) 'a20.g.akamai.net/A/IN'
> denied

Sure, I think we all get that.  Same as above.  But none of it is
"interesting".

> I've never established why this happens, whether it's some kind of
> attempt at cache poisoning from botnets or just broken software. But
> frankly I don't care - I just ignore it.

Of course.  So do I.  And I have been ignoring the queries I posted
about until I realized they had some interesting aspect to them.

Cheers,
b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20120724/eb33320a/attachment.bin>