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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users