🚀 go-pugleaf

In article bje@ripco.com says...
> 
> Mark Anderson <mea@nospambradnylion.com> wrote:
> 
> > I am now a bit more curious thus this post.
> 
> "The reason why it's sending the query over and over is because the DNS
> server is returning a DNS response of RCODE: 2 (ServFail), which is not a
> normal response. It indicates a server misconfiguration. If the server were
> to return the standard RCODE: 3 (NXDOMAIN) response, then mDNSResponder
> would stop sending queries. It's still a bug in mDNSResponder that it's not
> handling the ServFail very well, but it explains why only a few people are
> seeing this issue. Most people have DNS servers that return NXDOMAIN as the
> response."
> 
> It seems this bug comes up with various updates to OSX.

I went over the traces again and these devices aren't attempting any 
normal DNS.  They get an IP from my DHCP server and then they instantly 
start into IPv6 MDNS broadcasts which goes to every device that happened 
to be connected at the time.  Every now and then they'll dump a cache 
flush which is how I know that one device was my neighbor's because her 
computer name got dumped.  I see no normal traffic from anyone once the 
blasts start and in short time my server shuts off the interface for 
protection (my code).

A typical set of packet broadcasts look like this:

16:41:00.517556 60:33:4b:0a:8d:6d > 33:33:00:00:00:fb, ethertype IPv6 
(0x86dd), length 276: fe80::6233:4bff:fe0a:8d6d.mdns > ff02::fb.mdns: 0 
[2a] [6q] PTR (QM)? _apple-mobdev._tcp.local. PTR (QM)? _afpovertcp.
_tcp.local. PTR (QM)? _smb._tcp.local. PTR (QM)? _rfb._tcp.local. PTR 
(QM)? _adisk._tcp.local. PTR (QM)? _airport._tcp.local. (214)

16:41:00.517611 60:33:4b:0a:8d:6d > 33:33:00:00:00:fb, ethertype IPv6 
(0x86dd), length 86: fe80::6233:4bff:fe0a:8d6d > ff02::fb: HBH ICMP6, 
multicast listener reportmax resp delay: 0 addr: ff02::fb, length 24

over and over and over ad infinitum.

My servers simply ignore this.

> The simpliest solution it seems is to have only one dns entry on the 
macbook
> for the dns resolvers. With only one entry it'll time out even with the
> servfail being returned.

So it does sound like there may be something funny in the MacBook 
network stacks.  

> I dunno what you are doing with this network, handing out free wifi or
> whatever, but changing the dhcp configuration so the connecting computers
> only get one dns server should work also.

I do only give out one dns server IP in DHCP and I block all attempts to 
use an outside dns.  They must use my dns server.  It is funny how some 
devices try and try to use their own only to succumb to the Borg.  The 
bug here is in the MacBook's IPv6 stack and how they deal with mdns.  I 
heard Apple is big into MDNS whereas other device manufacturers don't 
use it that much if at all.

As for giving out free wifi, I'm giving out free wifi much like Facebook 
gives out "free" web services.  The devices that connect to my network 
unknowingly test various software I'm working on and contribute 
analytics for my study.  The bandwidth they use is rather trivial since 
I turn off Netflix streaming (a huge BW hog) and the well known porn 
streaming sites like xvideo.com and xhamster.com.  Once porno addicts 
get wind of free streaming my network will get overloaded with perverts  
so I shut it off.  Last year I had 1200 unique visitors averaging around 
250 unique visitors per month.  Lots of regulars and the number of 
tablets connecting is through the roof now.

My network is fairly secure from p2p abuse and other tom foolery but 
it's still a work in progress.  At first I thought these mdns blasts 
were malicious but now not so much.  I wonder how open wifis at places 
like Starbucks and McDonalds deal with these kind of situations since 
these blasts will bring down any open wifi.  Maybe they have access 
points that can deal with this -- I don't know.