Re: Comcast residential DNS contact
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: ma...@isc.org
RE: How to track DNS resolution sources
> Date: Wed, 3 Dec 2014 17:56:23 +0100 > From: bortzme...@nic.fr > To: notify.s...@gmail.com > Subject: Re: How to track DNS resolution sources > CC: nanog@nanog.org > > On Wed, Dec 03, 2014 at 05:22:58PM +0100, > Notify Me wrote > a message of 13 lines which said: > > > I hope I'm wording this correctly. > > Not really :-) > > > I had a incident at a client site where a DNS record was being > > spoofed. > > How do you know? What steps did you use to assert this? Answers to > these questions would help to understand your problem. > > > How does one track down the IP address that's returning the false > > records ? > > If it's real DNS spoofing (which I doubt), the source IP address of > the poisoner is forged, so it would not help. > > The main tool to use is dig. Let's assume the name that bothers you is > foobar.example.com. Query your local resolver: > > dig A foobar.example.com > > Query an external resolver, here Google Public DNS: > > dig @8.8.4.4 A foobar.example.com > > Query the authoritative name servers of example.com. First, to find them: > > dig NS example.com > > Second, query them (replace the server name by the real one): > > dig @a.iana-servers.net. A foobar.example.com I didn't understand how this will help him identify the poisoner. What an IDS rule will do is check for responding authoritative query IDs for DNS queries never made to that responder, but made for the authoritative server identified as per above (direct NS inquiry). If no IDS is present, BIND logging would allow for identification of authoritative responses and query ID identification. In summary whatever is answered authoritatively by a server other than the NS ones tracked by "dig +trace foobar.examplecom" is the potential poisoner. But if the poisoing is done from an spoofed IP address (spoofing the authoritative IP), well good luck w/ that if the spoofed domain is not DNSSEC aware.
Re: Transparent hijacking of SMTP submission...
> On Dec 1, 2014, at 5:25 AM, Livingood, Jason > wrote: > > On 11/29/14, 3:17 PM, "John Levine" wrote: > >> PS: I know enough technical people at Comcast that I would be >> extremely surprised if it were Comcast doing this. There's plenty not to >> like about the corporation, but the technical staff are quite competent. > > Thanks, John! I can tell folks here unequivocally that (1) the recent > press article on STARTTLS re-writing did *not* involve Comcast and (2) > Comcast does not engage in the claimed practice. In fact, weąre supporters > and early deployers of STARTTLS on our own mail service. > > I do not know how to explain the issue reported on this list. Absent a > packet capture it is impossible for me to analyze this further. If > anything, I could only imagine it was a misconfiguration someplace, but I > have no idea where or in what network element thatąd even be possible. Iąm > happy to work with anyone that has more info to try to troubleshoot this. > > - Jason Livingood > Comcast I have encountered similar issues on some hotel networks. Usually, a well meaning, but severely misinformed hotel administrator decides that: 1. People don’t know what they’re doing and configure they’re laptops to use their [corporate|home|usual] mailserver even when they’re on the road, often without authentication. 2. Debugging people’s laptops for them takes a lot of time and reduces customer satisfaction. so 3. Let’s just redirect all port 25/587 to our own local SMTP proxy which can’t possibly support TLS because we don’t have all the right certificates (nor should we), so it won’t announce the STARTLES capability. I don’t know if that’s what happened in this case, because, as you say, without first-hand information and packet-captures, it’s impossible to tell, but I will say that if you intend to use TLS, make sure your MUA REQUIRES TLS, rather than preferring TLS when available (as is default on many MUAs, unfortunately). Owen
Re: Comcast IPv6 issues..?
I will follow-up offline -Steve On Wed, Dec 3, 2014 at 3:40 PM, Stephen Frost wrote: > * Steve Meuse (sme...@mara.org) wrote: > > It's likely a reverse DNS error. If you look at the latency, it's within > > range of the previous hops. > > Still curious that the systems (IPv6 addresses) are changing too.. It's > not like it's the same route but just different rDNS results. It's also > quite a bit of latency between he.net and Comcast. Also seeing ~20% > packet loss to systems in Comcast and ~15% packet loss end-to-end. > Certainly seems like there's something unhappy there, but I'll just keep > an eye on it. > > Thanks! > > Stephen >
Re: Comcast IPv6 issues..?
* Steve Meuse (sme...@mara.org) wrote: > It's likely a reverse DNS error. If you look at the latency, it's within > range of the previous hops. Still curious that the systems (IPv6 addresses) are changing too.. It's not like it's the same route but just different rDNS results. It's also quite a bit of latency between he.net and Comcast. Also seeing ~20% packet loss to systems in Comcast and ~15% packet loss end-to-end. Certainly seems like there's something unhappy there, but I'll just keep an eye on it. Thanks! Stephen signature.asc Description: Digital signature
Re: Comcast IPv6 issues..?
It's likely a reverse DNS error. If you look at the latency, it's within range of the previous hops. -Steve On Wed, Dec 3, 2014 at 3:12 PM, Stephen Frost wrote: > Hey all, > > Getting delays and seeing some pretty funky routes inside Comcast. > All traces start from Ashburn, VA (2001:4830:167b::) and go to > Chicago, IL (2610:150:4b0f::). > > Coming from Occaid/SIXXS (over a tunnel) through HE.net and have seen: > > Ashburn -> San Jose -> New York -> Chicago > - > 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.955 ms > 10.583 ms 10.17 ms > 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.726 ms 11.004 ms > 9.956 ms > 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 10.069 > ms 10.674 ms 12.465 ms > 6 2001:559::db5 (2001:559::db5) 94.83 ms 95.593 ms 94.768 ms > 7 pos-2-2-0-0-cr01.sanjose.ca.ibone.comcast.net (2001:558:0:f58d::1) > 96.779 ms 99.591 ms 94.964 ms > 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) > 89.969 ms 91.143 ms 92.507 ms > 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net > (2001:558:0:f5b8::2) 97.411 ms 88.731 ms 87.457 ms > 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net > (2001:558:0:f8cc::2) 87.444 ms 88.756 ms 87.505 ms > 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 89.812 ms 88.774 ms 87.558 > ms > - > > Ashburn -> New York (but with lots of latency..) -> Chicago > - > 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.549 ms > 10.652 ms 10.107 ms > 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.975 ms 11.044 ms > 10.009 ms > 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 17.423 > ms 11.05 ms 12.27 ms > 6 2001:559::db5 (2001:559::db5) 95.197 ms 95.968 ms 94.793 ms > 7 he-2-6-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f8d2::1) > 105.158 ms 101.428 ms 94.993 ms > 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) > 89.735 ms 90.266 ms 92.577 ms > 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net > (2001:558:0:f5b8::2) 89.813 ms 92.963 ms 92.383 ms > 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net > (2001:558:0:f8cc::2) 87.401 ms 88.15 ms 87.085 ms > 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 122.387 ms 124.288 ms > 122.409 ms > - > > Ashburn -> Chicago -> New York -> Chicago > - > 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.926 ms > 10.183 ms 9.978 ms > 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.961 ms 11.37 ms > 9.973 ms > 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 9.95 > ms 18.258 ms 9.951 ms > 6 2001:559::db5 (2001:559::db5) 94.959 ms 96.413 ms 95.001 ms > 7 he-1-10-0-0-cr01.chicago.il.ibone.comcast.net (2001:558:0:f552::1) > 92.457 ms 92.964 ms 89.965 ms > 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) > 89.789 ms 91.291 ms 97.333 ms > 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net > (2001:558:0:f5b8::2) 87.518 ms 95.961 ms 87.506 ms > 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net > (2001:558:0:f8cc::2) 87.406 ms 86.414 ms 87.425 ms > 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 87.517 ms 86.589 ms 87.506 > ms > - > > Thoughts? > > Thanks, > > Stephen >
Comcast IPv6 issues..?
Hey all, Getting delays and seeing some pretty funky routes inside Comcast. All traces start from Ashburn, VA (2001:4830:167b::) and go to Chicago, IL (2610:150:4b0f::). Coming from Occaid/SIXXS (over a tunnel) through HE.net and have seen: Ashburn -> San Jose -> New York -> Chicago - 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.955 ms 10.583 ms 10.17 ms 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.726 ms 11.004 ms 9.956 ms 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 10.069 ms 10.674 ms 12.465 ms 6 2001:559::db5 (2001:559::db5) 94.83 ms 95.593 ms 94.768 ms 7 pos-2-2-0-0-cr01.sanjose.ca.ibone.comcast.net (2001:558:0:f58d::1) 96.779 ms 99.591 ms 94.964 ms 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) 89.969 ms 91.143 ms 92.507 ms 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net (2001:558:0:f5b8::2) 97.411 ms 88.731 ms 87.457 ms 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net (2001:558:0:f8cc::2) 87.444 ms 88.756 ms 87.505 ms 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 89.812 ms 88.774 ms 87.558 ms - Ashburn -> New York (but with lots of latency..) -> Chicago - 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.549 ms 10.652 ms 10.107 ms 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.975 ms 11.044 ms 10.009 ms 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 17.423 ms 11.05 ms 12.27 ms 6 2001:559::db5 (2001:559::db5) 95.197 ms 95.968 ms 94.793 ms 7 he-2-6-0-0-cr01.ashburn.va.ibone.comcast.net (2001:558:0:f8d2::1) 105.158 ms 101.428 ms 94.993 ms 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) 89.735 ms 90.266 ms 92.577 ms 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net (2001:558:0:f5b8::2) 89.813 ms 92.963 ms 92.383 ms 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net (2001:558:0:f8cc::2) 87.401 ms 88.15 ms 87.085 ms 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 122.387 ms 124.288 ms 122.409 ms - Ashburn -> Chicago -> New York -> Chicago - 3 sixxs-asbnva-gw.customer.occaid.net (2001:4830:e6:7::2) 9.926 ms 10.183 ms 9.978 ms 4 iad0-b0-ge2.hotnic.net (2001:4810:0:100::1) 9.961 ms 11.37 ms 9.973 ms 5 10gigabitethernet2-2.core1.ash1.he.net (2001:504:0:2::6939:1) 9.95 ms 18.258 ms 9.951 ms 6 2001:559::db5 (2001:559::db5) 94.959 ms 96.413 ms 95.001 ms 7 he-1-10-0-0-cr01.chicago.il.ibone.comcast.net (2001:558:0:f552::1) 92.457 ms 92.964 ms 89.965 ms 8 he-0-7-0-0-cr01.newyork.ny.ibone.comcast.net (2001:558:0:f5ba::2) 89.789 ms 91.291 ms 97.333 ms 9 he-0-11-0-0-cr01.350ecermak.il.ibone.comcast.net (2001:558:0:f5b8::2) 87.518 ms 95.961 ms 87.506 ms 10 he-0-10-0-0-pe04.350ecermak.il.ibone.comcast.net (2001:558:0:f8cc::2) 87.406 ms 86.414 ms 87.425 ms 11 2001:550:2:2::32:2 (2001:550:2:2::32:2) 87.517 ms 86.589 ms 87.506 ms - Thoughts? Thanks, Stephen signature.asc Description: Digital signature
Re: Comcast residential DNS contact
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 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 > >
IPligence contact?
if anyone has a live-person contact at geolocation provider IPligence (http://www.ipligence.com/) and can hit me up off-list, I would appreciate it. Thanks, Wesley George Time Warner Cable Anything below this line has been added by my company’s mail server, I have no control over it. --- This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Re: Comcast residential DNS contact
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 wrote: > On Wed, Dec 3, 2014 at 12:54 PM, Grant Ridder > 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) >
Re: Comcast residential DNS contact
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. asulli...@dyn.com v: +1 603 663 0448
Re: Comcast residential DNS contact
On Wed, Dec 3, 2014 at 12:54 PM, Grant Ridder 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)
Re: Transparent hijacking of SMTP submission...
There’s a big difference between illegal and civil liability for breech of contract. If I am paying someone for access to the internet, then I expect them not to modify, alter, rewrite, or otherwise interfere with my packets. If they do so, they may not have violated 47 USC 230, but they have certainly failed to provide the service that I am paying for. Uh huh. Please let us know the case number when you sue, so we can find out howthat pans out. By the way, I see you're a customer of Black Lotus. You might want to review sections 7 and 10 of the terms of service to which you've agreed: https://www.blacklotus.net/terms-of-service/ Your v6 traffic appears to arrive via a tunnel at HE. See sections 9 and 10 here, which you've also agreed to: http://www.he.net/tos.html R's, John
Re: Comcast residential DNS contact
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
Re: Comcast residential DNS contact
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 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 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 wrote: On 12/03/2014 04:04 AM, Niels Bakker wrote: > * shortdudey...@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. >>> >> >
Re: Comcast residential DNS contact
> On Dec 3, 2014, at 10:45 AM, Stephen Satchell 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-blacklist.txt or https://github.com/smurfmonitor/dns-iptables-rules/blob/master/domain-blacklist-string.txt - Jared
Re: Comcast residential DNS contact
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 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 wrote: >>> >>> On 12/03/2014 04:04 AM, Niels Bakker wrote: * shortdudey...@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. >>> >> >
Re: Transparent hijacking of SMTP submission...
I suspect it isn’t comcast at all. I suspect it is the wifi operator and they happen to use comcast as an upstream. The RDNS points to the public address in front of the wifi. The proxy doing the rewriting is likely behind that. Owen > On Nov 29, 2014, at 10:46 AM, Christopher Morrow > wrote: > > backing up a bit in the conversation, perhaps this is just in some > regions of comcastlandia? I don't see this in Northern Virginia... > > $ openssl s_client -starttls smtp -connect my-mailserver.net:587 > CONNECTED(0003) > depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = > my-mailserver.net, emailAddress = my-emailaddrss.com > verify error:num=20:unable to get local issuer certificate > verify return:1 > depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = my-mailsever.net, > emailAddress = my-emailaddress.com > verify error:num=27:certificate not trusted > verify return:1 > depth=0 description = kVjtrCL8rUdvd00q, C = US, CN = > my-mailserver.net, emailAddress = my-emailaddress.com > verify error:num=21:unable to verify the first certificate > verify return:1 > > ... > > Certificate chain > 0 > s:/description=kVjtrCL8rUdvd00q/C=US/CN=my-mailserver.net/emailAddress=y-emailaddress.com > i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate > Signing/CN=StartCom Class 1 Primary Intermediate Server CA > > ... > > New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: >Protocol : TLSv1.2 >Cipher: ECDHE-RSA-AES256-GCM-SHA384 >Session-ID: > FC3E47AF2A2A96BF6DE6E11F96B02A0C41A6542864271F2901F09594DE9A48FA >Session-ID-ctx: >Master-Key: > BE7FB76EF5C0A9BA507B175026F73E67080D6442201FDF28F536FA38197A9B1353D644EEAF8D0D264328F94B2EF5742C >Key-Arg : None >PSK identity: None >PSK identity hint: None >SRP username: None >Start Time: 1417286582 >Timeout : 300 (sec) >Verify return code: 21 (unable to verify the first certificate) > --- > 250 DSN > ehlo me > 250-my-mailserver.net > 250-PIPELINING > > > On Sat, Nov 29, 2014 at 12:26 PM, Jean-Francois Mezei > wrote: >> On 14-11-29 11:07, Sander Steffann wrote: >> >>> I am so glad that our Dutch net neutrality laws state that "providers of >>> Internet access services may not hinder or delay any services or >>> applications on the Internet" (unless [...], but those exceptions make >>> sense) >> >> >> However, in the case of SMTP, due to the amount of spam, most ISPs break >> "network neutrality" by blocking outbound port 25 for instance, and >> their SMTP servers will block much incoming emails (spam). However, >> SMTP is a layer or two above the network. But blocking port 25 is at the >> network level. >> >> I have seen wi-fi systems where you ask to connect to 20.21.22.23 port >> 25, and you get connected to 50.51.52.53 port 25. (the ISPs own SMTP >> server). I would rather they just block it than redirect you without >> warning to an SMTP server of their own where they can look and your >> outbound email, pretend to acccept it, and never deliver it. >> >> >>
Re: Transparent hijacking of SMTP submission...
There’s a big difference between illegal and civil liability for breech of contract. If I am paying someone for access to the internet, then I expect them not to modify, alter, rewrite, or otherwise interfere with my packets. If they do so, they may not have violated 47 USC 230, but they have certainly failed to provide the service that I am paying for. Owen > On Nov 29, 2014, at 12:17 PM, John Levine wrote: > >> i think of it as an intentional traffic hijack. i would be talking to a >> lawyer. > > If the lawyer says anything other than that 47 USC 230(c)(2)(A) > provides broad immunity for ISP content filtering, even if the filters > sometimes screw up, you need a new lawyer. > > Filtering STARTTLS on port 587 is pretty stupid, but not everything > that's stupid is illegal. > > R's, > John > > PS: I know enough technical people at Comcast that I would be > extremely surprised if it were Comcast doing this. There's plenty not > to like about the corporation, but the technical staff are quite > competent.
Re: Google contact: apps vs IPv6 issue
On 2014-12-03 17:57, Max Tulyev wrote: > Hello! > > Could someone advice a good contact inside Google? n...@google.com is where this stuff has to go. They claim to read it (and mostly they do in time). > I'm operating a IPv6 tunnel broker http://tb.netassist.ua/ > > Now there are a number of complaints tunnel broker users can't access > Google Apps with the reason "We're sorry, but this service is not > available in your country". That is likely as your address space has shown users with cookies from a variety of locations not matching where you claim they are coming. Note that Happy Eyeballs causes folks to use IPv4 + IPv6 and thus mismatches are easily caught by sites that care to pay attention to that. > IPv4 access to same pages from Ukraine is OK, and MaxMind GeoIP replies > our IPv6 network we are using in our service is "NetAssist, Ukraine". You might want to implement: http://tools.ietf.org/html/draft-google-self-published-geofeeds-02 See also for a bit more user-sided detail: https://www.sixxs.net/faq/misc/?faq=geolocation Do note that you need to have a good trust factor there for Google to accept the geofeed. Greets, Jeroen
Re: How to track DNS resolution sources
On Wed, Dec 03, 2014 at 11:32:08AM -0500, TR Shaw wrote a message of 20 lines which said: > On the command line: > > host spoofed.host.name.com Excuse me but it is useless. It tests only the local resolver (which may be unpoisoned). It provides no details that could help to debug the problem (such as the TTL).
Google contact: apps vs IPv6 issue
Hello! Could someone advice a good contact inside Google? I'm operating a IPv6 tunnel broker http://tb.netassist.ua/ Now there are a number of complaints tunnel broker users can't access Google Apps with the reason "We're sorry, but this service is not available in your country". IPv4 access to same pages from Ukraine is OK, and MaxMind GeoIP replies our IPv6 network we are using in our service is "NetAssist, Ukraine".
Re: How to track DNS resolution sources
On Wed, Dec 03, 2014 at 05:22:58PM +0100, Notify Me wrote a message of 13 lines which said: > I hope I'm wording this correctly. Not really :-) > I had a incident at a client site where a DNS record was being > spoofed. How do you know? What steps did you use to assert this? Answers to these questions would help to understand your problem. > How does one track down the IP address that's returning the false > records ? If it's real DNS spoofing (which I doubt), the source IP address of the poisoner is forged, so it would not help. The main tool to use is dig. Let's assume the name that bothers you is foobar.example.com. Query your local resolver: dig A foobar.example.com Query an external resolver, here Google Public DNS: dig @8.8.4.4 A foobar.example.com Query the authoritative name servers of example.com. First, to find them: dig NS example.com Second, query them (replace the server name by the real one): dig @a.iana-servers.net. A foobar.example.com
Re: How to track DNS resolution sources
On the command line: host spoofed.host.name.com On Dec 3, 2014, at 11:22 AM, Notify Me wrote: > Hi! > > I hope I'm wording this correctly. I had a incident at a client site where > a DNS record was being spoofed. How does one track down the IP address > that's returning the false records ? What tool can one use? > > Thanks! > > > > > -- > Sent from MetroMail
How to track DNS resolution sources
Hi! I hope I'm wording this correctly. I had a incident at a client site where a DNS record was being spoofed. How does one track down the IP address that's returning the false records ? What tool can one use? Thanks! -- Sent from MetroMail
Re: Comcast residential DNS contact
On 12/3/14, 6:53 AM, "Grant Ridder" 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.
Re: Comcast residential DNS contact
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 wrote: On 12/03/2014 04:04 AM, Niels Bakker wrote: * shortdudey...@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.
Re: Comcast residential DNS contact
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 wrote: >> >>> On 12/03/2014 04:04 AM, Niels Bakker wrote: >>> * shortdudey...@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.
Re: Comcast residential DNS contact
So have A record queries. Do you filter those as well? Jared Mauch > On Dec 3, 2014, at 9:08 AM, Stephen Satchell wrote: > >> On 12/03/2014 04:04 AM, Niels Bakker wrote: >> * shortdudey...@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.
Re: Comcast residential DNS contact
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 wrote: > On 12/03/2014 04:04 AM, Niels Bakker wrote: >> * shortdudey...@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
Re: Comcast residential DNS contact
On 12/03/2014 04:04 AM, Niels Bakker wrote: > * shortdudey...@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.
Re: Phasing out of copper
In the same breath, Bell says they want the CRTC to deregulate copper, as it is no longer essential. I know right now, that if ULLs were forborne, we would not have a suitable substitute for our co-locate served customers. In 5 to 10 years, that might be a different story, but today it is not. Bell wants the freedom to deploy fibre networks without mandated wholesale but also wants to de-regulate copper loops while still using them for their own purposes as long as is convenient simply because for 99% of the customers today, DSL speeds are what they choose, and copper loops for now are the most cost effective way to provide those speeds or just plain dialtone. A bit of a have your cake & eat it too attitude, which is exactly what I expect from Bell. At 09:51 PM 02/12/2014, Jean-Francois Mezei wrote: One reason is that by pretending that copper is here to stay and is competitive, they hope to convicne CRTC that mandating wholesale access to FTTP is not necessary. --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409
Re: Comcast residential DNS contact
* shortdudey...@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.
Re: Comcast residential DNS contact
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 wrote: > > * shortdudey...@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.
Re: Comcast residential DNS contact
* shortdudey...@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.
Re: Hibernia/Atrato contacts
Thanks for the information. I've got a few contacts now and will be reaching out to them. On 3 Dec 2014 02:13, "Alistair Mackenzie" wrote: > Hi, > > Does anyone have a contact for a sales/account manager at Hibernia/Atrato > located in the UK timezone or even +1? > > Please contact me off list with the details. > > Thanks, > Alistair >
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
