Print

[snarked]

I have rate limiting enabled in my DNS server.  I’m getting rate limiting messages in my system logs for DNS queries that appear to be from HE’s tunnel server.  Example:

11-Sep-2021 08:23:52.542 client @0x7fcf905af6e0 66.220.18.42#26678 (DELETED-bl.snarked.net): rate limit slip NODATA response to 66.220.18.0/24 for DELETED-bl.snarked.net IN  (2d03f8d7)

I see no reason for a tunnel server to be the source of a query for any hosted domain outside of HE itself.  Is there a security hole permitting them to be open resolvers?

I have masked the actual query by deleting part of it, but left enough of it to show that it is a DNSBL entry, not a hostname query.  Why would a tunnel server be checking my private list (and furthermore, the list being checked is not an IPv4, IPv6, or a domain name list, but something else)?  66.220.18.42 is the Los Angeles tunnel server endpoint address.

[mikma]

Is there a security hole permitting them to be open resolvers?

Hurricane Electric has public DNS resolvers (2001:470:20::2 and 74.82.42.42). They seem to use the tunnel endpoint addresses for outbound DNS requests. Is that a problem?

[snarked]

That explains it.  I was expecting (only) and I’m also seeing the open resolver addresses as query sources.  According to the tunnel documentation, the tunnel address is supposed to be used only for tunnel functions (i.e. encapsulated tunneled packets and the periodic keep-alive pings).  There was no mention of the public resolvers being (anycasted) from the same machines as the tunnel servers.

Problem?  I also have a very strict firewall, and the excessive DNS queries from a source that apparently shouldn’t be sending them was causing the tunnel IPv4 address to be auto-blacklisted.  In order to trigger rate limiting, the content of the DNS queries is also repetitive and/or abusive.  Fortunately, I also have the tunnel addresses whitelisted but only for encapsulated packets, so I had no loss of tunnel function.