Can someone from Comcast that works with the customer resolvers (
cdns01.comcast.net / cdns02.comcast.net) please contact me off list? The
01 resolver is sometimes not returning complete results when the DNS query
type is set to ANY for $dayjob's domain.
-Grant
* shortdudey123@gmail.com (Grant Ridder) [Wed 03 Dec 2014, 10:49 CET]:
Can someone from Comcast that works with the customer resolvers ( cdns01.comcast.net / cdns02.comcast.net) please contact me off list? The 01 resolver is sometimes not returning complete results when the DNS query type is set to ANY for $dayjob's domain.
That's how DNS works, yes.
-- Niels.
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?
-Grant
* shortdudey123@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.
-- Niels.
At the ISP I consult to, I filter all ANY queries, because they have
been used for DNS amplification attacks.
Hello!
But any other DNS type can be used for DNS amplification. RRL is right
solution for amplification issue. I recommend NSD DNS server because
it's reliable, has complete support of DNSSEC, IPv6 and RRL.
So have A record queries. Do you filter those as well?
Jared Mauch
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.
Shouldn't everyone be on IPv6 these days anyway 
Comparing different resolvers often compares how the different developers
of DNS software have chosen to implement the RFCs.
I¹m curious what the exact query is.
Jason Livingood
Comcast
PS - I emailed you off-list.
Hi Everyone,
Thanks for the replies! After reading them, i am doing some digging into
DNS RFC's and haven't found much with respect to ANY queries. Not
responding with full results to protect against being used in an attack
makes sense. However, I find it odd that only 1 of the 4 anycast servers I
tried would institute this.
Also, as a side note, i hit all 4 anycast servers on both v4 and v6 with
similar results already.
-Grant
You should not filter the any queries, perhaps you want to TC=1 them. I
created a patch for bind for this purpose.
http://puck.nether.net/~jared/bind-9.9.3rc2-tcp-any.patch
I’ve seen many of these attacks, they will use MX/TXT/A and other records.
You may want to look at some of the public resources for this, e.g.:
http://dnsamplificationattacks.blogspot.nl/
is a good one and for the git lovers:
https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blacklist.txt
or
https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blacklist-string.txt
- Jared
Did more digging and found the RFC regarding ANY queries:
3.2.3 - * 255 A request for all records
https://www.ietf.org/rfc/rfc1035.txt
However Wikipedia (http://en.wikipedia.org/wiki/List_of_DNS_record_types)
lists this as a request for "All cached records" instead of "A request for
all records" per the RFC.
-Grant
Did more digging and found the RFC regarding ANY queries:
3.2.3 - * 255 A request for all records
https://www.ietf.org/rfc/rfc1035.txt
When listing URLs for RFCs it's better to use the tools site, as it gives a much better experience:
https://tools.ietf.org/html/rfc1035
Meanwhile, the text is correct, but what you're missing is the nuance of authoritative vs. recursive. If you send an ANY query to an authoritative server it is naturally going to send you all of the related records, since it has them all.
A recursive (or iterative if you prefer) server only has what it has in the cache, but it will send you "all records" that it has. What this does not imply is that the recursive server will go out and do its own ANY query for the RR you're asking about, unless there is nothing in the cache to start with.
There are any number of explanations for why some of the recursive servers you're querying have more records than others. None of them are bugs. 
However Wikipedia (http://en.wikipedia.org/wiki/List_of_DNS_record_types)
lists this as a request for "All cached records" instead of "A request for
all records" per the RFC.
Wikipedia is good for a lot of things, but standards work is not one of them. The text above is a good example of why.
Doug
it's possible (jason hinted at this) that the servers in question are
not a homogeneous software set... and have different behaviour being
displayed because of that.
Also, just because you sent a packet to 4 different ip addresses
doesn't mean that they didn't end up on one or some of the same hosts
behind loadbalancers/ecmp/etc, right? (so it's not clear you are/can
test this properly from your vantage point)
-chris
(what's a bit concerning is my comcast link's not able to talk to
cdns02 at all... over ipv4 at least, v6 works, thankfully I suppose)
Those two turn out to mean the same thing in the way the DNS community
has come to understand the semantics of the * query.
A resolver that has a cache is able to answer the query for * by
consulting its cache. There is no signal in the DNS that there are
records for other RRTYPEs at the same owner name and class, so the
resolver is in a position to answer the question, and so it does.
Certainly, the authoritative resolver will always give you every
record at that owner name and class in the authoritative zone in the
event you asked that.
Also, you probably want to look at RFC 4592, which considerably
expands the treatment of wildcards in the DNS.
Best regards,
A
It's also entirely possible that the behavior observed will change because
of testing. The more a test looks different from "normal" residential
traffic the more likely that it's going to be handled differently.
Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000
Ah that makes sense. I am not going to worry about the inconstancy then.
Thanks to everyone that replied!!
-Grant
DNS Cookies / SIT (DNS Cookies w/o the error code) will also deal
with forged traffic. It allows you to identify traffic from a
client that you have replied to in the past and to which you can
safely send a large response. It lets you sort the wheat from the
chaff.
https://tools.ietf.org/html/draft-ietf-dnsop-cookies-00
SIT is available in BIND 9.10 (configure --enable-sit) and uses a
experiment EDNS OPT code. BIND 9.11 will have DNS Cookies / SIT
will on by default with a allocated code point.
The only thing is the amount of non EDNS compliance with servers
will make this hard to deploy. In theory unknown EDNS options are
supposed to be IGNORED (See RFC6891, 6.1.2 Wire Format). This was
done to allow you to send a EDNS option without knowing if the other
end supported that option safely.
http://users.isc.org/~marka/ts/gov.optfail.html
Unfortunately there are firewalls that block such queries. There
are nameserver implementations that return FORMERR when they see
such queries. There are nameserver implementations that return
BADVER when they see such queries. There are nameserver implemations
that echo back the option. There are also implementations that
don't return a EDNS response unless DO=1 is set.
If your nameserver / firewall combination fails to properly handle
EDNS queries with unknown options can you please fix it.
You can test EDNS option handling with the following allocated code
points.
dig +nsid soa $zone @$server
dig +expire soa $zone @$server
Experimentatal code point (requires BIND 9.10).
dig +sit soa $zone @$server
Unallocated code point (requires pre BIND 9.11 code from sources.isc.org).
dig +ednsopt=100 soa $zone @$server
There are also issues with attempting to use a new EDNS version
(this should get BADVERS returned) or setting a new EDNS flag bit
(supposed to be ignored). Firewalls also stupidly block these even
more so than unknown EDNS options.
http://users.isc.org/~marka/ts.html
Mark