Comcast residential DNS contact
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
On Dec 3, 2014, at 2:51 AM, Niels Bakker <niels=nanog@bakker.net> wrote:
* 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.
* 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.
On 12/03/2014 04:04 AM, Niels Bakker wrote:
* 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.
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. On Wed, Dec 3, 2014 at 5:08 PM, Stephen Satchell <list@satchell.net> wrote:
On 12/03/2014 04:04 AM, Niels Bakker wrote:
* 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.
At the ISP I consult to, I filter all ANY queries, because they have been used for DNS amplification attacks.
-- Sincerely yours, Pavel Odintsov
So have A record queries. Do you filter those as well? Jared Mauch
On Dec 3, 2014, at 9:08 AM, Stephen Satchell <list@satchell.net> wrote:
On 12/03/2014 04:04 AM, Niels Bakker wrote: * 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.
At the ISP I consult to, I filter all ANY queries, because they have been used for DNS amplification attacks.
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@satchell.net> wrote:
On 12/03/2014 04:04 AM, Niels Bakker wrote: * 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.
At the ISP I consult to, I filter all ANY queries, because they have been used for DNS amplification attacks.
On Dec 3, 2014, at 10:45 AM, Stephen Satchell <list@satchell.net> wrote:
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.
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-blackl... or https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blackl... - Jared
Shouldn't everyone be on IPv6 these days anyway ;) On 12/3/2014 10: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@satchell.net> wrote:
On 12/03/2014 04:04 AM, Niels Bakker wrote: * 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. At the ISP I consult to, I filter all ANY queries, because they have been used for DNS amplification attacks.
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 On Wed, Dec 3, 2014 at 7:46 AM, Brian Rak <brak@gameservers.com> wrote:
Shouldn't everyone be on IPv6 these days anyway ;)
On 12/3/2014 10: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@satchell.net> wrote:
On 12/03/2014 04:04 AM, Niels Bakker wrote:
* 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.
At the ISP I consult to, I filter all ANY queries, because they have been used for DNS amplification attacks.
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 On Wed, Dec 3, 2014 at 9:54 AM, Grant Ridder <shortdudey123@gmail.com> wrote:
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
On Wed, Dec 3, 2014 at 7:46 AM, Brian Rak <brak@gameservers.com> wrote:
Shouldn't everyone be on IPv6 these days anyway ;)
On 12/3/2014 10: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@satchell.net> wrote:
On 12/03/2014 04:04 AM, Niels Bakker wrote:
* 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.
At the ISP I consult to, I filter all ANY queries, because they have been used for DNS amplification attacks.
On 12/3/14 10:07 AM, Grant Ridder wrote:
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
Ah that makes sense. I am not going to worry about the inconstancy then. Thanks to everyone that replied!! -Grant On Wed, Dec 3, 2014 at 10:30 AM, Doug Barton <dougb@dougbarton.us> wrote:
On 12/3/14 10:07 AM, Grant Ridder wrote:
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
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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, Dec 03, 2014 at 10:07:04AM -0800, Grant Ridder wrote:
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.
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 -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
On Wed, Dec 3, 2014 at 12:54 PM, Grant Ridder <shortdudey123@gmail.com> wrote:
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.
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)
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 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Wed, Dec 3, 2014 at 1:37 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Dec 3, 2014 at 12:54 PM, Grant Ridder <shortdudey123@gmail.com> wrote:
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.
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)
On 12/3/14, 6:53 AM, "Grant Ridder" <shortdudey123@gmail.com> wrote:
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?
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.
participants (12)
-
Andrew Sullivan -
Brian Rak -
Christopher Morrow -
Doug Barton -
Grant Ridder -
Jared Mauch -
Livingood, Jason -
Mark Andrews -
Niels Bakker -
Pavel Odintsov -
Scott Helms -
Stephen Satchell