Comcast residential DNS contact

Stephen Satchell list at satchell.net
Wed Dec 3 15:45:48 UTC 2014


No.  When I've been victim of DNS amplification attacks, the packet
capture showed that the attacker used ANY queries.  Legit ANY queries on
my recursive servers?  Damn few.  So I block.  Not so on my
authoritative servers, where ANY queries on the domains I host zone
files for have not caused any problems, for anyone.

Another thing I did was slow down the port for my recursive DNS servers
to 10 megabits/s.  That means that my upstream link can't be saturated
by DNS amplification.  Oh, and I rate-limit incoming queries to my DNS
servers by IP address range -- an attack from one subnet won't affect
queries from other parts of the net.  Queries from my IP address range
have a high cap; J random IP addresses have a lower cap.

On 12/03/2014 07:28 AM, Jared Mauch wrote:
> So have A record queries. Do you filter those as well?
> 
> Jared Mauch
> 
>> On Dec 3, 2014, at 9:08 AM, Stephen Satchell <list at satchell.net> wrote:
>>
>>> On 12/03/2014 04:04 AM, Niels Bakker wrote:
>>> * shortdudey123 at gmail.com (Grant Ridder) [Wed 03 Dec 2014, 12:54 CET]:
>>>> Both of Google’s public DNS servers return complete results every time
>>>> and one of the two comcast ones works fine.
>>>>
>>>> If this is working by design, can you provide the RFC with that info?
>>>
>>> An ANY query will typically return only what's already in the cache.  So
>>> if you ask for MX records first and then query the same caching resolver
>>> for ANY it won't return, say, any TXT records that may be present at the
>>> authoritative nameserver.
>>>
>>> This could be implementation dependent, but Comcast's isn't wrong, and
>>> you should not rely on ANY queries returning full data.  This has been
>>> hashed out to tears in the past, for example when qm**l used to do these
>>> queries in an attempt to optimise DNS query volumes and RTT.
>>
>> At the ISP I consult to, I filter all ANY queries, because they have
>> been used for DNS amplification attacks.




More information about the NANOG mailing list