Re: [dns-operations] DNS-OARC Fall 2014 Workshop - Los Angeles, California, 11th-13th October
On 11 Sep 2014, at 3:54, Keith Mitchell ke...@dns-oarc.net wrote: I can confirm that we still have *plenty* of capacity in our room block until CoB today, and having also just tried it the link certainly stil works for me. Is it possible you asked for dates outside our 10th-17th October window ? I tried multiple times, 10th-16th, but no matter, I'm booked now -- I just couldn't use the group code. Joe ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Botnets, botnets everywhere
Hello, We run a public resolver and a few days ago I noticed a lot of very weird queries, like the following: 16:11:41.450794 IP 217.195.66.253.37426 62.76.76.62.53: 42580+ A? swfjwvtkhqx.www.feile.com. (47) 16:11:41.450796 IP 91.209.124.75.50584 62.76.76.62.53: 37269+ [1au] A? izhsccxedub.www.feile666.com. (57) For the total amount of SLDs of 11, the only common in those queries are random labels on the left side. One of those SLDs is an online-shop, another is online-casino, so I concluded that our resolver is being used to bombard NSes of corresponding SLDs with queries. I'd like to ask the respected community, how do you detect and protect against such activity? Will RRL help me if all suspected queries come with random qname? Thank you in advance. -- Is there any problem Exterminatus cannot solve? I have not found one yet. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] 167.216.129.170 RDNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello All, I am having difficulty resolving Reverse DNS for 167.216.129.170, and I'm not entirely certain why. If I just do a dig -x 167.216.129.170 I get: ; DiG 9.7.3 -x 167.216.129.170 ;; global options: +cmd ;; connection timed out; no servers could be reached If I dig -x +trace 167.216.129.170: ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 28671 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;167.216.129.170. IN A ;; AUTHORITY SECTION: . 10549 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014091100 1800 900 604800 86400 and finally, if I dig -x 167.216.129.170 @8.8.8.8: ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 58383 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;170.129.216.167.in-addr.arpa. IN PTR ;; ANSWER SECTION: 170.129.216.167.in-addr.arpa. 3047 IN CNAME 170.0-24.129.216.167.in-addr.arpa. 170.0-24.129.216.167.in-addr.arpa. 3047 IN PTR nmail2.netsuite.com. This is impacting my ability to receive transactional emails from this IP address in particular. My DNS server is running Bind 9.7.3 on Debian Squeeze. I thought perhaps my DNS server was being blocked, but that wouldn't explain the NXDOMAIN I don't believe. I apologize in advance if this is something simple and/or obvious, but can anyone explain what is happening and/or how to correct it? Many thanks in advance! Regards, dtb Dave Brockman Senior Network Engineer - -- Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network. RFC 1925 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUEZrqAAoJEMP+wtEOVbcdBFcH/jS+6PLbOG7pGXSlxZJ5XFMi l4GC1kF/ukrwh4wzUr2kKOXpBnO0H9DPMOpJN4TG2ABNDrfubciMNtKXLQCw33jU U/v3OiBv9LlziKZ+keD8Fg1dTKTUM74rIkCtN8LzkQT0eGeBj53nnAG+Q/8kMefF 7MlmM6SPZYd7NxrCSgs2jO/Y5hXnIOKh8FRPhOKU5vou+iKbOPp+Uuvi4drozhXZ 2iGOQ/mwo79SaGynHNTZeo6zjOR9U5W5zH8TdVZz//589lvtqIdybjOzfuQmXo+G 7e+yzvKw9dl2frf59+2jMVKKQ2LAyyAMKcrwIU8SyzglyMNNlwSv01Abuo+89jg= =YaMy -END PGP SIGNATURE- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
On Sep 11, 2014, at 8:42 PM, Peter Andreev andreev.pe...@gmail.com wrote: I'd like to ask the respected community, how do you detect and protect against such activity? What we've seen of this particular attack methodology (as you rightly deduced) over the last six months or so indicates that the placement of the prefix is consistent, as is the size. So, if you have the ability to perform regexp-type filtering on the queries you receive on ingress, that's one possible answer (unless/until the attack using/creating this particular attack script changes things up). FYI, most of these queries seem to be reflected through abusable CPE devices which are misconfigured by default as open recursors or DNS forwarders. It may be worth considering investigating, and if this proves to be the case, blacklisting those netblocks and contacting the operator(s) in question in order to ask them to remediate the nodes in question (this could all be scripted, along with a periodic check which would remove the blacklisting once remediation occurs). --- Roland Dobbins rdobb...@arbor.net ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
On Sep 11, 2014, at 8:42 PM, Peter Andreev andreev.pe...@gmail.com wrote: One of those SLDs is an online-shop, another is online-casino, so I concluded that our resolver is being used to bombard NSes of corresponding SLDs with queries. Also, in some cases, we've seen this activity constitute a reflection/amplification attack against the recursive DNS infrastructure of broadband and IDC operators who're using public open recursors as their external resolvers. So, looking at the purported querier addresses might provide some insight into which scenario applies in any given instance. --- Roland Dobbins rdobb...@arbor.net ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
On Thu, Sep 11, 2014 at 04:38:25PM +0400, Peter Andreev wrote: I'd like to ask the respected community, how do you detect and protect against such activity? Will RRL help me if all suspected queries come with random qname? No, it will probably not, since the answers are all servfails. PowerDNS Recursor 3.6.0 and beyond contain logic that globally detects nameservers that are already dead, and stops sending further queries, it can reduce flow by 99% for example (with only 1 infrequent ping query to see if a server is up again). But we still get flooded by the traffic which wastes CPU and degrades performance. http://comments.gmane.org/gmane.network.dns.operations/3764 this thread has some wisdom too on generating filters for BIND. It should be possible to do this in some smarter fashion within a nameserver, but the real solution is to target the clients sending you such queries, which tend to be DNS forwarders or botnet members in their own right. There is far more harm they could inflict otherwise.. -- PowerDNS Website: http://www.powerdns.com/ Contact us by phone on +31-15-7850372 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
On Thu, Sep 11, 2014 at 04:38:25PM +0400, Peter Andreev andreev.pe...@gmail.com wrote a message of 29 lines which said: a lot of very weird queries, like the following: 16:11:41.450794 IP 217.195.66.253.37426 62.76.76.62.53: 42580+ A? swfjwvtkhqx.www.feile.com. (47) 16:11:41.450796 IP 91.209.124.75.50584 62.76.76.62.53: 37269+ [1au] A? izhsccxedub.www.feile666.com. (57) Looks like the random qnames attack http://www.michael-joost.de/dnsterror.html ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] 167.216.129.170 RDNS
Another data point for you: On Aug 28, I wrote this open message on the NANOG mailing list: I discovered that NetSuite's dns servers ens0 1 .netsuite.com are invisible from Comcast's business services in the Chicago area(limits of my testing abilities) but I can reach these same servers from a Linode virtual system in the Dallas, TX area. Looks like it's been this way for at least two months. If someone from NetSuite could say hi and look into it, I am sure it will help NetSuite more than me. Lyle Giese LCR Computer Services, Inc. I never heard back from anyone, but I can reach them today from my Comcast business connection in the Chicago area right now. On 09/11/14 07:51, Dave Brockman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello All, I am having difficulty resolving Reverse DNS for 167.216.129.170, and I'm not entirely certain why. If I just do a dig -x 167.216.129.170 I get: ; DiG 9.7.3 -x 167.216.129.170 ;; global options: +cmd ;; connection timed out; no servers could be reached If I dig -x +trace 167.216.129.170: ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 28671 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;167.216.129.170. IN A ;; AUTHORITY SECTION: . 10549 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014091100 1800 900 604800 86400 and finally, if I dig -x 167.216.129.170 @8.8.8.8: ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 58383 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;170.129.216.167.in-addr.arpa. IN PTR ;; ANSWER SECTION: 170.129.216.167.in-addr.arpa. 3047 IN CNAME 170.0-24.129.216.167.in-addr.arpa. 170.0-24.129.216.167.in-addr.arpa. 3047 IN PTR nmail2.netsuite.com. This is impacting my ability to receive transactional emails from this IP address in particular. My DNS server is running Bind 9.7.3 on Debian Squeeze. I thought perhaps my DNS server was being blocked, but that wouldn't explain the NXDOMAIN I don't believe. I apologize in advance if this is something simple and/or obvious, but can anyone explain what is happening and/or how to correct it? Many thanks in advance! Regards, dtb Dave Brockman Senior Network Engineer - -- Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network. RFC 1925 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUEZrqAAoJEMP+wtEOVbcdBFcH/jS+6PLbOG7pGXSlxZJ5XFMi l4GC1kF/ukrwh4wzUr2kKOXpBnO0H9DPMOpJN4TG2ABNDrfubciMNtKXLQCw33jU U/v3OiBv9LlziKZ+keD8Fg1dTKTUM74rIkCtN8LzkQT0eGeBj53nnAG+Q/8kMefF 7MlmM6SPZYd7NxrCSgs2jO/Y5hXnIOKh8FRPhOKU5vou+iKbOPp+Uuvi4drozhXZ 2iGOQ/mwo79SaGynHNTZeo6zjOR9U5W5zH8TdVZz//589lvtqIdybjOzfuQmXo+G 7e+yzvKw9dl2frf59+2jMVKKQ2LAyyAMKcrwIU8SyzglyMNNlwSv01Abuo+89jg= =YaMy -END PGP SIGNATURE- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] 167.216.129.170 RDNS
In message 54119aeb.8070...@brockmans.com, Dave Brockman writes: Hello All, I am having difficulty resolving Reverse DNS for 167.216.129.170, and I'm not entirely certain why. If I just do a dig -x 167.216.129.170 I get: ; DiG 9.7.3 -x 167.216.129.170 ;; global options: +cmd ;; connection timed out; no servers could be reached If I dig -x +trace 167.216.129.170: The command you want is dig -x 167.216.129.170 +trace or dig +trace -x 167.216.129.170 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] 167.216.129.170 RDNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you, and thank you Mark for reminding me to start my coffee :) Regards, dtb On 9/11/2014 9:13 AM, Lyle Giese wrote: Another data point for you: On Aug 28, I wrote this open message on the NANOG mailing list: I discovered that NetSuite's dns servers ens0 1 .netsuite.com are invisible from Comcast's business services in the Chicago area(limits of my testing abilities) but I can reach these same servers from a Linode virtual system in the Dallas, TX area. Looks like it's been this way for at least two months. If someone from NetSuite could say hi and look into it, I am sure it will help NetSuite more than me. Lyle Giese LCR Computer Services, Inc. I never heard back from anyone, but I can reach them today from my Comcast business connection in the Chicago area right now. On 09/11/14 07:51, Dave Brockman wrote: Hello All, I am having difficulty resolving Reverse DNS for 167.216.129.170, and I'm not entirely certain why. If I just do a dig -x 167.216.129.170 I get: ; DiG 9.7.3 -x 167.216.129.170 ;; global options: +cmd ;; connection timed out; no servers could be reached If I dig -x +trace 167.216.129.170: ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 28671 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;167.216.129.170. IN A ;; AUTHORITY SECTION: . 10549 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014091100 1800 900 604800 86400 and finally, if I dig -x 167.216.129.170 @8.8.8.8: ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 58383 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;170.129.216.167.in-addr.arpa. IN PTR ;; ANSWER SECTION: 170.129.216.167.in-addr.arpa. 3047 IN CNAME 170.0-24.129.216.167.in-addr.arpa. 170.0-24.129.216.167.in-addr.arpa. 3047 IN PTR nmail2.netsuite.com. This is impacting my ability to receive transactional emails from this IP address in particular. My DNS server is running Bind 9.7.3 on Debian Squeeze. I thought perhaps my DNS server was being blocked, but that wouldn't explain the NXDOMAIN I don't believe. I apologize in advance if this is something simple and/or obvious, but can anyone explain what is happening and/or how to correct it? Many thanks in advance! Regards, dtb Dave Brockman Senior Network Engineer -- Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network. RFC 1925 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs - -- Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network. RFC 1925 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJUEaRIAAoJEMP+wtEOVbcdvc8H/Aj9kiGxGt3ax1sI2KyAE2Tx PkiYiBPHkdveS7nSjXZzDEVSa2JexdzKqa9stFNwFXMDqUvJU1/IGGxYBVpbHl1M v4XRZmcJ2v+lVHo6ZUD8JL1gSYRkY0UvUcuKeL9+vTj8nBxSWGwb+ravIrFjpcDf 35cSntJ8ZcmC5VX9WA2I3GrVJPwEMR5bPwzTM/swFk4kCiV8vYnFhMAngyABYAAb CD2PJT7vaf96Ul3oAiwKNXM/fJIFS39zsO3S/A/bloxNVU9rbPZYCWmhhRmbAWNX 51+zoEzprljBp1qI1/nh5NNsLEal0Yyh/6sRiQJoiHIdhAqZ4c/y2ONaRd0nBJk= =3Tgr -END PGP SIGNATURE- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
On Thu, Sep 11, 2014 at 09:00:37PM +0800, Roland Dobbins rdobb...@arbor.net wrote a message of 29 lines which said: FYI, most of these queries seem to be reflected through abusable CPE devices which are misconfigured by default as open recursors or DNS forwarders. It may be worth considering investigating, and if this proves to be the case, blacklisting those netblocks and contacting the operator(s) in question Many open resolvers do not forward directly but send to a big resolver such as Google Public DNS (which you cannot obviously blacklist). The authoritative name servers therefore do not see directly the open resolver. Source: Open Resolvers in COM/NET Resolution by Duane Wessels at OARC 2014 https://indico.dns-oarc.net/conferenceTimeTable.py?confId=19#20140511 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
On Sep 11, 2014, at 9:46 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote: Many open resolvers do not forward directly but send to a big resolver such as Google Public DNS (which you cannot obviously blacklist). The authoritative name servers therefore do not see directly the open resolver.] Yes. The blacklisting recommendation is for the open resolver operator who is seeing the queries/responses in question (i.e., the OP in this thread). --- Roland Dobbins rdobb...@arbor.net ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
Many registries, if not most, don't let you delegate a zone to arbitrary name-servers. Instead those nameservers need to be registered in some way. Typically anyone can register a name server, and it once it's done, many zones can be delegated to that name server. A small number of CC-TLDs also require contact details for the name servers, but I only know of two that do that. Registering doesn't require setting up glue, and it doesn't look it's being done to detect cyclic dependencies between zones, which is also the only limitation in the DNS that I can think of that require some kind of workaround. So why is it that name servers need to be registered? What's the benefit of doing it? and if anyone can register a name server, what's the point? -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
That's exactly my case with the only difference - mathematics doesn't work for me. However I like author's idea and going to try to find similar coincedences. 2014-09-11 17:11 GMT+04:00 Stephane Bortzmeyer bortzme...@nic.fr: On Thu, Sep 11, 2014 at 04:38:25PM +0400, Peter Andreev andreev.pe...@gmail.com wrote a message of 29 lines which said: a lot of very weird queries, like the following: 16:11:41.450794 IP 217.195.66.253.37426 62.76.76.62.53: 42580+ A? swfjwvtkhqx.www.feile.com. (47) 16:11:41.450796 IP 91.209.124.75.50584 62.76.76.62.53: 37269+ [1au] A? izhsccxedub.www.feile666.com. (57) Looks like the random qnames attack http://www.michael-joost.de/dnsterror.html -- Is there any problem Exterminatus cannot solve? I have not found one yet. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
Colm For gTLDs the nameservers have to be registered via a registrar Some of the ccTLDs also demand payment and other oddness for adding them I suspect a lot of this is legacy .. no idea though Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.technology.ie http://www.blacknight.press for all our news media Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Twitter: http://twitter.com/mneylon --- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 -Original Message- From: dns-operations [mailto:dns-operations-boun...@dns-oarc.net] On Behalf Of Colm MacCárthaigh Sent: Thursday, September 11, 2014 3:53 PM To: dns-operations@lists.dns-oarc.net Subject: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to? Many registries, if not most, don't let you delegate a zone to arbitrary name-servers. Instead those nameservers need to be registered in some way. Typically anyone can register a name server, and it once it's done, many zones can be delegated to that name server. A small number of CC-TLDs also require contact details for the name servers, but I only know of two that do that. Registering doesn't require setting up glue, and it doesn't look it's being done to detect cyclic dependencies between zones, which is also the only limitation in the DNS that I can think of that require some kind of workaround. So why is it that name servers need to be registered? What's the benefit of doing it? and if anyone can register a name server, what's the point? -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On Thu, Sep 11, 2014 at 07:52:31AM -0700, Colm MacCárthaigh c...@stdlib.net wrote a message of 26 lines which said: So why is it that name servers need to be registered? What's the benefit of doing it? As an employee of a registry which does not require name server registration, I wonder, too :-) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On Thu, Sep 11, 2014 at 07:52:31AM -0700, Colm MacCárthaigh wrote: Many registries, if not most, don't let you delegate a zone to arbitrary name-servers. Instead those nameservers need to be registered in some way. I don't know about other kinds of registration systems, but in EPP-based ones this is a consequence of one of the variants of the data model. In EPP, there are two ways to create name servers. One is as an attribute of the domain object. The other is as an association between a domain object and a host object. What you're seeing, I expect, as the registration is in fact the creation of the host object. The host-object approach has a particular advantage. It isn't quite true that _anyone_ can create a host object. External hosts (i.e. out-of baliwick, such as ns1.example.com in the .info registry) can indeed normally be created by anyone and normally do not take an IP address (it's a bad idea to have glue there, because it's out-of-baliwick). But internal hosts take glue, and they are not allowed to be created unless the superordinate name exists (i.e. you can't create ns1.example.org in the org registry unless example.org has already been created; this is required by RFC 5732). In at least one registry implementation of which I am aware, the server policy was that the sponsor of the host object in the repository had to be the same as the sponsor of the superordinate domain object (that is, RegistrarA couldn't create a host in example.info if example.info was registered by RegistrarB). This may have been our interpretation of the then-existing EPP draft, though I suspect we did it for convenience. I can't recall. My reading of RFC 5732 is that it does not require this. The particular advantage that the host-object approach has is that the original creator of an internal host object gives it an IP address, and everyone gets the same IP address thereafter. If the address changes, it changes once for everyone in the registry. This in fact models what happens on the Internet when you renumber a host. It's terrible for registry operators, of course, but it's good data practice. None of this matters for out-of-baliwick name servers, but it'd be a bad idea to mix and match the host-object and nameserver-attribute approaches in the same registry, so EPP prohibits repository operators from doing both at the same time (A server operator MUST use one name server specification form consistently, saith RFC 5731). Anyway, I suspect that's the reason for what you observe. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
Hi, Guess the first people are now finding out that .prod went live. I heard from a large webhoster that their sysadmins use db1.prod for a shorthand of db1.prod.corp.com. They are now attempting to go to the 127.0.53.53 warning pit. I had never through of prod being a problem. but it might actualy be a pretty big one, along with stag if that is ever delegated. Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
I'd always thought that this was kinda because of the way EPP is written -- not that it is actually required, but when reading the docs you see the nameservers object and kinda assume... I think at this point much of it is hysterical raisons. W On Thursday, September 11, 2014, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Thu, Sep 11, 2014 at 07:52:31AM -0700, Colm MacCárthaigh c...@stdlib.net javascript:; wrote a message of 26 lines which said: So why is it that name servers need to be registered? What's the benefit of doing it? As an employee of a registry which does not require name server registration, I wonder, too :-) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net javascript:; https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
[dns-operations] is there a diagnostic tool to obtain delegated ns?
I'm going to be open sourcing a php class I wrote awhile back that we use internally for finding the delegated nameservers for a specified domain. This is distinct from host -C or doing a type=ns query because while those will look at what are *thought* to be the NS records for the domain (as reported by the nameservers themselves), it is not uncommon to be at variance from what's actually delegated into the roots. The class is just a wrapper that steps through dig +trace, but before I clean this up, etc I'm wondering if we re-invented a wheel somewhere along the line. Is there already any tool specifically outputs the authoritative nameservers as they are delegated in the rootzone for a domain? - mark -- Mark E. Jeftovic mar...@easydns.com Founder CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] is there a diagnostic tool to obtain delegated ns?
On Thu, 11 Sep 2014 12:19:00 -0400 Mark E. Jeftovic mar...@easydns.com wrote: Is there already any tool specifically outputs the authoritative nameservers as they are delegated in the rootzone for a domain? I did something close to this years ago. It looks like it even still works. :-) I don't think this is quite what you're looking for, but maybe it is useful to you? http://layer9.com/~jtk/software/glue-report John ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
Perhaps they need to set the ‘ndots’ option in resolv.conf to trigger absolute queries if they find more than 1 dot, so something like: options ndots 2 would prevent a query to the .prod. TLD. from ‘man resolv.conf’ ndots:n sets a threshold for the number of dots which must appear in a name given to res_query(3) (see resolver(3)) before an initial absolute query will be made. The default for n is 1, meaning that if there are any dots in a name, the name will be tried first as an absolute name before any search list elements are appended to it. The value for this option is silently capped to 15. francisco On Sep 11, 2014, at 9:07 AM, Paul Wouters p...@nohats.ca wrote: Hi, Guess the first people are now finding out that .prod went live. I heard from a large webhoster that their sysadmins use db1.prod for a shorthand of db1.prod.corp.com. They are now attempting to go to the 127.0.53.53 warning pit. I had never through of prod being a problem. but it might actualy be a pretty big one, along with stag if that is ever delegated. Paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
Thanks for the explanation, that helps! If we step back from the practise, do we think it's a good thing? One the one hand, requiring that nameservers be registered creates downward pressure on the number of active authoritative name server names in the world, which has benefits for cache efficiencies (ie many zones delegated to the same names). One the other hand, it can be beneficial to give every zone unique name server names (in-zone vanity names, or otherwise), even if those names resolve to the same name-servers. That would makes it easier to manage single zone migrations and things like DDOS isolation. These days I think it might be as common to move a single zone around as it is to renumber a host. On Thu, Sep 11, 2014 at 9:06 AM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Sep 11, 2014 at 07:52:31AM -0700, Colm MacCárthaigh wrote: Many registries, if not most, don't let you delegate a zone to arbitrary name-servers. Instead those nameservers need to be registered in some way. I don't know about other kinds of registration systems, but in EPP-based ones this is a consequence of one of the variants of the data model. In EPP, there are two ways to create name servers. One is as an attribute of the domain object. The other is as an association between a domain object and a host object. What you're seeing, I expect, as the registration is in fact the creation of the host object. The host-object approach has a particular advantage. It isn't quite true that _anyone_ can create a host object. External hosts (i.e. out-of baliwick, such as ns1.example.com in the .info registry) can indeed normally be created by anyone and normally do not take an IP address (it's a bad idea to have glue there, because it's out-of-baliwick). But internal hosts take glue, and they are not allowed to be created unless the superordinate name exists (i.e. you can't create ns1.example.org in the org registry unless example.org has already been created; this is required by RFC 5732). In at least one registry implementation of which I am aware, the server policy was that the sponsor of the host object in the repository had to be the same as the sponsor of the superordinate domain object (that is, RegistrarA couldn't create a host in example.info if example.info was registered by RegistrarB). This may have been our interpretation of the then-existing EPP draft, though I suspect we did it for convenience. I can't recall. My reading of RFC 5732 is that it does not require this. The particular advantage that the host-object approach has is that the original creator of an internal host object gives it an IP address, and everyone gets the same IP address thereafter. If the address changes, it changes once for everyone in the registry. This in fact models what happens on the Internet when you renumber a host. It's terrible for registry operators, of course, but it's good data practice. None of this matters for out-of-baliwick name servers, but it'd be a bad idea to mix and match the host-object and nameserver-attribute approaches in the same registry, so EPP prohibits repository operators from doing both at the same time (A server operator MUST use one name server specification form consistently, saith RFC 5731). Anyway, I suspect that's the reason for what you observe. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On Thu, Sep 11, 2014 at 09:34:32AM -0700, Colm MacCárthaigh wrote: Thanks for the explanation, that helps! If we step back from the practise, do we think it's a good thing? From the point of view of data management, I think it is an unalloyed good. I always thought the nameserver-as-attribute approach was dramatically worse. Particularly for internal host objects, the enforced consistency of the glue for every domain that's using it is a giant help. One the other hand, it can be beneficial to give every zone unique name server names (in-zone vanity names, or otherwise), even if those names resolve to the same name-servers. Yes, although with the increasing amount of outsourcing of DNS, I think you're bound to see a mix of unique names and very widely-shared names. Also, it's not like it's terrifically onerous, although I know some registrars' web interfaces for this are messy and confusing. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
Vanity nameservers would not be very useful in DDoS mitigation (in terms of isolating your target) unless you actually create unique IP address nameserver records for each one. That's all you'll see in the attack, which IP's the attack is coming toward, not the hostnames of the vanity nameservers themselves (although I suppose it's possible the botnet would constantly be doing DNS lookups of those vanity nameservers, but they could just as easily do it once, at the beginning of the attack and then cache their responses). - mark Colm MacCárthaigh wrote: Thanks for the explanation, that helps! If we step back from the practise, do we think it's a good thing? One the one hand, requiring that nameservers be registered creates downward pressure on the number of active authoritative name server names in the world, which has benefits for cache efficiencies (ie many zones delegated to the same names). One the other hand, it can be beneficial to give every zone unique name server names (in-zone vanity names, or otherwise), even if those names resolve to the same name-servers. That would makes it easier to manage single zone migrations and things like DDOS isolation. These days I think it might be as common to move a single zone around as it is to renumber a host. On Thu, Sep 11, 2014 at 9:06 AM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Sep 11, 2014 at 07:52:31AM -0700, Colm MacCárthaigh wrote: Many registries, if not most, don't let you delegate a zone to arbitrary name-servers. Instead those nameservers need to be registered in some way. I don't know about other kinds of registration systems, but in EPP-based ones this is a consequence of one of the variants of the data model. In EPP, there are two ways to create name servers. One is as an attribute of the domain object. The other is as an association between a domain object and a host object. What you're seeing, I expect, as the registration is in fact the creation of the host object. The host-object approach has a particular advantage. It isn't quite true that _anyone_ can create a host object. External hosts (i.e. out-of baliwick, such as ns1.example.com in the .info registry) can indeed normally be created by anyone and normally do not take an IP address (it's a bad idea to have glue there, because it's out-of-baliwick). But internal hosts take glue, and they are not allowed to be created unless the superordinate name exists (i.e. you can't create ns1.example.org in the org registry unless example.org has already been created; this is required by RFC 5732). In at least one registry implementation of which I am aware, the server policy was that the sponsor of the host object in the repository had to be the same as the sponsor of the superordinate domain object (that is, RegistrarA couldn't create a host in example.info if example.info was registered by RegistrarB). This may have been our interpretation of the then-existing EPP draft, though I suspect we did it for convenience. I can't recall. My reading of RFC 5732 is that it does not require this. The particular advantage that the host-object approach has is that the original creator of an internal host object gives it an IP address, and everyone gets the same IP address thereafter. If the address changes, it changes once for everyone in the registry. This in fact models what happens on the Internet when you renumber a host. It's terrible for registry operators, of course, but it's good data practice. None of this matters for out-of-baliwick name servers, but it'd be a bad idea to mix and match the host-object and nameserver-attribute approaches in the same registry, so EPP prohibits repository operators from doing both at the same time (A server operator MUST use one name server specification form consistently, saith RFC 5731). Anyway, I suspect that's the reason for what you observe. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark E. Jeftovic mar...@easydns.com Founder CEO, easyDNS Technologies Inc. +1-(416)-535-8672 ext 225 Read my blog: http://markable.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
On 11/09/2014 13:38, Peter Andreev wrote: Hello, We run a public resolver and a few days ago I noticed a lot of very weird queries, like the following: 16:11:41.450794 IP 217.195.66.253.37426 62.76.76.62.53: 42580+ A? swfjwvtkhqx.www.feile.com. (47) 16:11:41.450796 IP 91.209.124.75.50584 62.76.76.62.53: 37269+ [1au] A? izhsccxedub.www.feile666.com. (57) For the total amount of SLDs of 11, the only common in those queries are random labels on the left side. One of those SLDs is an online-shop, another is online-casino, so I concluded that our resolver is being used to bombard NSes of corresponding SLDs with queries. I'd like to ask the respected community, how do you detect and protect against such activity? Will RRL help me if all suspected queries come with random qname? Thank you in advance. There's a lot of this about. We did awhile back wonder if it was botnet-related, but I've not (yet) seen any persuasive evidence that it is. Our current thinking (based on evidence from some of our customers, and also from Nominum's analysis presented at the Warsaw DNS-OARC workship earlier this year) that the majority of these recent query spates are intended as an attack on the domain (e.g. feile.com) or the nameserver hosting it. Once overwhelmed with query traffic, the DNS servers cease responding, or only respond sporadically. These authoritative server admins may also be deploying RRL to protect themselves too - but from your perspective, they're non-responding either way (with one exception - which is if they respond with the TC bit set to encourage a TCP-based query instead). The attackers appear to be making use of open resolvers (lists of which are readily available) presumably in order to ensure that the queries come from a whole range of clients, and possibly to provide another level of obscurity for the actual source. If you're running a public recursive server, you may be seeing the queries both directly and indirectly. The indirect queries are likely being forwarded to you by other servers or by insecure CPE devices that proxy queries to port 53 on their WAN interface by forwarding them to the ISP provider's DNS servers. There are quite a few things you can do to alleviate the problem, including limiting access to your open resolvers, identifying and blocking traffic that is coming to you via broken CPE devices, and identifying and communicating with admins of open resolvers that are forwarding to you. Other techniques include making yourself authoritative for the domains that are under attack (you can usually identify them from the traffic - some admins have scripted solutions), and/or using a DNS RPZ domain to block the queries - although you need a version of DNS RPZ that includes the qname-wait-recurse option that you'll want to set to 'yes' to make the rewriting occur prior to iteration. If you're running BIND, we're working on some new recursive rate limiting techniques that we're quite keen to get more exposure to - they involve rate-limiting queries to servers that are becoming non-responsive. I presented on the most recent evolution of those earlier this week at UKNOF29 in Belfast (they were earlier aired at IETF90 in Toronto and some useful suggestions taken on-board). https://indico.uknof.org.uk/conferenceOtherViews.py?view=standardconfId=31 See Nominum's session at 9:40 with further analysis of the traffic, and mine at 10:00 on various mitigation techniques. Hope this helps? (And also, I'm very keen to hear/see evidence of other causes and sources of this type of query traffic) Cathy ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On Thu, Sep 11, 2014 at 12:46:50PM -0400, Andrew Sullivan wrote: On Thu, Sep 11, 2014 at 09:34:32AM -0700, Colm MacCárthaigh wrote: Thanks for the explanation, that helps! If we step back from the practise, do we think it's a good thing? From the point of view of data management, I think it is an unalloyed good. I always thought the nameserver-as-attribute approach was dramatically worse. Particularly for internal host objects, the enforced consistency of the glue for every domain that's using it is a giant help. This holds only with a very specific delegation/glue policy. I know registries where the delegation/glue policy leads to a much better fit using host-atributes. Please let's not revive old provreg holy wars ;-) Fred ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
Our current thinking (based on evidence from some of our customers, and also from Nominum's analysis presented at the Warsaw DNS-OARC workship earlier this year) that the majority of these recent query spates are intended as an attack on the domain (e.g. feile.com) or the nameserver hosting it. Once overwhelmed with query traffic, the DNS servers cease responding, or only respond sporadically. Being responsible for the recursive name servers for a large Norwegian ISP, I see these attacks on a more or less daily basis, mostly due to CPEs with DNS proxies open towards the Internet. I am reasonably sure that the attack is on the authoritative name servers, and not on the domains as such. This conclusion is based on the following (which is obviously not *proof*): - Some of the domains have only been registered a few days before an attack starts. - There are obvious similarities in the non-random part of many of these domain names which seems to indicate that they are *generated*, e.g. www.6644qq.com www.6644se.com www.6655pp.com www.6655qq.com www.667788.com www.6688hh.com www.6688pp.com or dafa888567.com dafa888678.com dafa888789.com dafa888cg.com dafa888vd.com Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
Although the attack could be done with a botnet or by reflecting traffic off end-user equipment, many of the attacks I have seen involve source IP spoofing. I deduce this by noting that a fairly large percentage of the traffic comes from blocks of IPs that are not currently routed on the open Internet. What I see is typically a mix of obviously spoofed (non-routed) and routed addresses. The routed addresses may also be spoofed - but this is much harder to determine. E.g. the following snippet from my borders, where N indicates non-routed source address and the 195.204.57.* hosts are CPEs with open DNS proxies: 21:55:46.739163 IP 53.48.96.141.51437 195.204.57.162.53: 35936+ A? kvudwxmqder.www.dafa888789.com. (48) 21:55:46.796523 IP 55.163.252.238.27190 195.204.57.164.53: 60924+ A? mtkvc.dafa888567.com. (38) N 21:55:46.850267 IP 102.106.11.104.54844 195.204.57.162.53: 26379+ A? nopqefguvwxyz.dafa888567.com. (46) 21:55:46.863560 IP 64.25.179.88.12684 195.204.57.162.53: 22451+ A? qofrmtalrde.www.dafa888789.com. (48) N 21:55:46.942008 IP 11.217.253.15.4803 195.204.57.164.53: 3837+ A? oxhbpbd.dafa888678.com. (40) 21:55:47.096952 IP 14.75.14.130.10520 195.204.57.162.53: 33038+ A? abpqeftuiwxyz.dafa888678.com. (46) 21:55:47.118716 IP 70.34.188.220.18210 195.204.57.176.53: 56252+ A? oxcfidszqpunuf.dafa888567.com. (47) 21:55:47.161832 IP 41.103.81.228.41650 195.204.57.164.53: 58193+ A? dcyhjqf.www.dafa888789.com. (44) 21:55:47.277108 IP 41.100.100.63.46343 195.204.57.162.53: 15972+ A? abcdrfthiwkyz.dafa888567.com. (46) 21:55:47.343137 IP 53.165.159.154.2278 195.204.57.162.53: 39327+ A? ttvpzgrpncilyhb.dafa888567.com. (48) 21:55:47.369258 IP 68.15.126.166.1222 195.204.57.164.53: 42366+ A? hjghdju.dafa888678.com. (40) N 21:55:47.386443 IP 101.35.159.246.26686 195.204.57.162.53: 62879+ A? j.dafa888567.com. (34) N 21:55:47.388156 IP 21.212.28.24.17856 195.204.57.162.53: 5916+ A? v.dafa888567.com. (34) 21:55:47.415251 IP 18.82.142.16.45236 195.204.57.164.53: 3982+ A? bymbjomwk.dafa888678.com. (42) However - whether the source address is spoofed or not, in the end it still generates the same attack on the authoritative name servers (in this case ns1.haodns.in and ns2.haodns.in, as far as I can see). I wonder the extent to which the end-user equipment is being blamed when it's just routed IPs which are being used. I don't really see a contradiction between CPEs with open DNS proxies and DNS queries from routed IPs. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/2014 9:07 AM, Paul Wouters wrote: Guess the first people are now finding out that .prod went live. I heard from a large webhoster that their sysadmins use db1.prod for a shorthand of db1.prod.corp.com. They are now attempting to go to the 127.0.53.53 warning pit. I had never through of prod being a problem. but it might actualy be a pretty big one, along with stag if that is ever delegated. i've been helping folks configure DNS RPZ on their recursive name servers in a way that reverts .PROD lookups to the previous NXDOMAIN behaviour, thus fixing their apparent stub-resolver client breakage. of course the real problem is using nonqualified names, but since that has worked reliably for several decades, we can expect a long tail of adaptation. for the time being, and perhaps for a long time to come, the people who call the presence of .PROD a bug and/or depend on its absence as a feature, outnumbers and will outnumber the people who call it a feature or who will call its absence a bug. see also https://www.icann.org/en/system/files/files/sac-064-en.pdf. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
In message caaf6gdejb5nw40m4ew58vxwssmlzroeaxvb0vtptf_kfwd+...@mail.gmail.com , =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= writes: On Thu, Sep 11, 2014 at 9:46 AM, Andrew Sullivan a...@anvilwalrusden.com wro te: Also, it's not like it's terrifically onerous, although I know some registrars' web interfaces for this are messy and confusing. I do think that the policies of the .is GLTD are a net harm for DNS. They require that DNS servers respond to queries they aren't authoritative for (e.g. a SERVFAIL, or a REFUSED). Besides the reflection attack risk, this also means the behavior-of-last-resort should be respond with an error: but I'd prefer to leave the question unanswered in case another name server for the domain does know how to serve the query. For example if a provider booted a box with an empty configuration, it would be much better to timeout queries than respond with SERVFAIL or REFUSED. Actually timeout is much, much, much worse. Authoritatively say I am here, your query did not get lost, I don't have the answer you want lets recursive server move on to the next server without having to timeout the query. Delegation should never succeed unless you can get a SOA response for the zone being delegated from the nameservers being delegated to. How hard is it to make a SOA query to confirm that the zone is configured? That query should be followed using EDNS with a unknown option, and a unknown flag set. This query should also be responded to. If a OPT record is returned the rcode needs to be NOERROR and the unknown option and the unknown flag both need to not exist. If you got a OPT record with this second query you should send a third query with the EDNS version set to a unknown value. This should elicit a BADVERS response. It any of the EDNS queries timeout the nameserver is BROKEN and the delegation should not be permitted to proceed until the server is fixed. DNS is a query / response protocol. Responses are expected to queries. DNS COOKIES and other extension are going to be hard to deploy unless we start checking for and removing broken nameservers and firewalls from the ecosystem. Checking at delegation time is a good way to stop things getting worse. -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
Robert wrote: Can't you win in either case? If they don't re-resolve you could just move everyone else off of those IPs by updating the DNS entries for the unique nameserver labels to those zones. If they do re-resolve you just move that single unique name to a different IP. I'm not sure what you mean by re-resolve, do you mean re-delegate? You could move everybody off of the ns set under attack, it's easier to do if they are all using the same nameserver records (provided you've isolated the domain under attack and changed it's delegation to something else first). It would be harder to do that if each domain were using it's own vanity NS. In fact in times we've done pretty well that, the domains using vanity nameservers - pointed at our IPs (without us even realizing it[1]) had the effect of those domains being left behind in the move. In either case having the flexibility to affect change at the single zone seems desirable - why would I want my domain to be tied to the fate of your zone? As Colm points out the tradeoff here is between cache-ability of nameserver records vs shared fate. Yes, I think having that flexibility is very important and handy, I'm just not sure vanity nameservers - in the way I understand that to mean - gets you there. Having a unique set of nameserver permutations per zone could get you there. If you have three /24's, one for each nameserver node, you could have over 15 million permutations. We're in the process of moving toward that sort of a methodology. - mark [1] Which brings up an old gripe I've had for a long time, if we're going to talk about registry rules on creating nameserver records, wouldn't it be nice, shouldn't it be nice, for nameserver operators to have some sort of mechanism to approve or at least *refute* domains that may delegate to them, perhaps without their knowledge or against their best interests? In other words, it would be nice to be able to undelegate a domain from one's own nameservers without having the co-operation of the domain's registrar. .r' Colm MacCárthaigh wrote: Thanks for the explanation, that helps! If we step back from the practise, do we think it's a good thing? One the one hand, requiring that nameservers be registered creates downward pressure on the number of active authoritative name server names in the world, which has benefits for cache efficiencies (ie many zones delegated to the same names). One the other hand, it can be beneficial to give every zone unique name server names (in-zone vanity names, or otherwise), even if those names resolve to the same name-servers. That would makes it easier to manage single zone migrations and things like DDOS isolation. These days I think it might be as common to move a single zone around as it is to renumber a host. On Thu, Sep 11, 2014 at 9:06 AM, Andrew Sullivan a...@anvilwalrusden.com wrote: On Thu, Sep 11, 2014 at 07:52:31AM -0700, Colm MacCárthaigh wrote: Many registries, if not most, don't let you delegate a zone to arbitrary name-servers. Instead those nameservers need to be registered in some way. I don't know about other kinds of registration systems, but in EPP-based ones this is a consequence of one of the variants of the data model. In EPP, there are two ways to create name servers. One is as an attribute of the domain object. The other is as an association between a domain object and a host object. What you're seeing, I expect, as the registration is in fact the creation of the host object. The host-object approach has a particular advantage. It isn't quite true that _anyone_ can create a host object. External hosts (i.e. out-of baliwick, such as ns1.example.com in the .info registry) can indeed normally be created by anyone and normally do not take an IP address (it's a bad idea to have glue there, because it's out-of-baliwick). But internal hosts take glue, and they are not allowed to be created unless the superordinate name exists (i.e. you can't create ns1.example.org in the org registry unless example.org has already been created; this is required by RFC 5732). In at least one registry implementation of which I am aware, the server policy was that the sponsor of the host object in the repository had to be the same as the sponsor of the superordinate domain object (that is, RegistrarA couldn't create a host in example.info if example.info was registered by RegistrarB). This may have been our interpretation of the then-existing EPP draft, though I suspect we did it for convenience. I can't recall. My reading of RFC 5732 is that it does not require this. The particular advantage that the host-object approach has is that the original creator of an internal host object gives it an IP address, and everyone gets the same IP address thereafter. If the address changes, it changes once for everyone in the registry. This in fact models what happens on the Internet when you renumber
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On Thu, Sep 11, 2014 at 5:03 PM, Mark Andrews ma...@isc.org wrote: Which indicates broken recursive servers. Recursive servers should be expecting misconfigured authoritative servers. You don't stuff up authoritative behaviour because you have broken recursive servers. I do whatever is best for customers: partially delayed resolution, which is then mitigated by caching, is better than partial outages. -- Colm ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] is there a diagnostic tool to obtain delegated ns?
Is there already any tool specifically outputs the authoritative nameservers as they are delegated in the rootzone for a domain? res_findzonecut(), inside libbind (now called netresolv), provides an API that does what you don't want (gets the zone's apex NS RRset), but is implemented with logic you could hack to grab the information you do want (the closest ancestor's delegation NS RRset), as it goes by. http://wiki.netbsd.org/individual-software-releases/netresolv/ vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
From the point of view of data management, I think it is an unalloyed good. I always thought the nameserver-as-attribute approach was dramatically worse. Particularly for internal host objects, the enforced consistency of the glue for every domain that's using it is a giant help. It was curious to see that a to-be-unnamed TLD registry, a newcomer to the scene many years after the holy wars that ended up defining the current RFCs, writing completely new code, mentioned that they found attributes to be a better option, but decided to go with host objects due to registrar support. This doesn't prove which way is better, but for me it indicates that the role in the value chain can play a part in which option is preferred. Rubens ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On 9/11/2014 5:22 PM, Colm MacCárthaigh wrote: On Thu, Sep 11, 2014 at 5:03 PM, Mark Andrews ma...@isc.org wrote: Which indicates broken recursive servers. Recursive servers should be expecting misconfigured authoritative servers. You don't stuff up authoritative behaviour because you have broken recursive servers. I do whatever is best for customers: partially delayed resolution, which is then mitigated by caching, is better than partial outages. i don't agree i think it's better for your customers if they see an outage. because that outcome has some hope of forcing the broken authority servers to feel some heat. if you act as an enabler for bad authority server behaviour, then that behaviour can become entrenched. giving away your first-mover advantage will hurt your customers, a lot, in the long run. and my customers, too. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Dumb question: why is it that some registries limit the nameservers that can be delegated to?
On Thu, Sep 11, 2014 at 09:35:40PM -0300, Rubens Kuhl wrote: It was curious to see that a to-be-unnamed TLD registry, a newcomer to the scene many years after the holy wars that ended up defining the current RFCs, writing completely new code, mentioned that they found attributes to be a better option Well, note, the RFCs actually allow you to do one or the other, so there was no victor in the war. Many people when designing a new registry think attributes are better because they don't create cross-object links. If you come from the database side of the house (which I do), you are given shudders because of the potential for data inconsistency in glue. Lots of new registries don't have a glue problem early on, and so this never seems like it's worth worrying about. That's the real reason I prefer the host-object approach. But like Frederico, I don't want to reignite a controversy. better, but for me it indicates that the role in the value chain can play a part in which option is preferred. Yes. Interoperability is way more important that just about anything else on the Internet. A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/2014 6:30 PM, Paul Vixie wrote: ... i have a lot of data but no obvious way to distill this determination out of it. as to this part, let me quote what i said on another mailing list earlier today, on a similar thread (.PROD collisions): On 9/11/2014 2:57 PM, Paul Vixie wrote: ... so, we (farsight security; home of SIE and DNSDB) do not currently store or measure NXDOMAIN traffic, but it has seemed to me that with ~350 name servers sending us ~150K cache miss transactions per second, we ought to be able to see contrails from gTLD collisions. if anybody has a proposal for a (not-for-fee) experiment, or (not-for-fee) continuous monitoring, i'm all ears. vixie that offer is generally open to unfunded nonprofit DNS researchers who want to help study collisions. contact me directly if you're interested. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
Probably something I should know. But what's the best way to get notified of new TLDs coming online to help arm the NOC? -- Josh Smith KD8HRX Email/jabber: juice...@gmail.com Phone: 304.237.9369(c) Sent from my iPhone. On Sep 11, 2014, at 9:32 PM, Paul Vixie p...@redbarn.org wrote: On 9/11/2014 6:30 PM, Paul Vixie wrote: ... i have a lot of data but no obvious way to distill this determination out of it. as to this part, let me quote what i said on another mailing list earlier today, on a similar thread (.PROD collisions): On 9/11/2014 2:57 PM, Paul Vixie wrote: ... so, we (farsight security; home of SIE and DNSDB) do not currently store or measure NXDOMAIN traffic, but it has seemed to me that with ~350 name servers sending us ~150K cache miss transactions per second, we ought to be able to see contrails from gTLD collisions. if anybody has a proposal for a (not-for-fee) experiment, or (not-for-fee) continuous monitoring, i'm all ears. vixie that offer is generally open to unfunded nonprofit DNS researchers who want to help study collisions. contact me directly if you're interested. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On Thu, Sep 11, 2014 at 09:58:59PM -0400, Joshua Smith wrote: Probably something I should know. But what's the best way to get notified of new TLDs coming online to help arm the NOC? Probably the _best_ way is to get copies of the root zone. There's also http://newgtlds.icann.org/en/program-status/delegated-strings, but it explicitly says that it's not being updated in real time. You can find out whether something will _eventually_ be delegated by looking at https://gtldresult.icann.org/application-result/applicationstatus. If you look at completed PDT, that tells you that they've completed the pre-delegation testing, so they're going to be delegated at some point. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
In message 45b62715-b7f9-439e-81b3-6c7356e88...@vpnc.org, Paul Hoffman writes : On Sep 11, 2014, at 4:27 PM, Paul Vixie p...@redbarn.org wrote: for the time being, and perhaps for a long time to come, the people who call the presence of .PROD a bug and/or depend on its absence as a feature, outnumbers and will outnumber the people who call it a feature or who will call its absence a bug. How do you measure that? This is a serious question, one that affects DNS ope rators. If you have a way of determining how many enterprises are negatively affected as a new gTLD rolls out, that would be very useful information. I just wish I had been able to convince Paul to remove support for partially qualified names back when RFC 1535 came out. We knew then that they were a bad idea. ndots minimises the damage of using partially qualified names. It doesn't remove it. The real fix is make the resolver libraries not append search lists entries to names with multiple labels. Yes, people need to type slightly long names or add more search list entries. Yes there will be some pain but it is something better done sooner rather than later. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/14 6:58 PM, Joshua Smith wrote: Probably something I should know. But what's the best way to get notified of new TLDs coming online to help arm the NOC? https://gtldresult.icann.org/application-result/applicationstatus hth, Doug ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/2014 7:08 PM, Mark Andrews wrote: ... I just wish I had been able to convince Paul to remove support for partially qualified names back when RFC 1535 came out. We knew then that they were a bad idea. ndots minimises the damage of using partially qualified names. It doesn't remove it. at the time (1993?) i felt it was best not to break anybody's existing configuration. that seems insane now. The real fix is make the resolver libraries not append search lists entries to names with multiple labels. Yes, people need to type slightly long names or add more search list entries. Yes there will be some pain but it is something better done sooner rather than later. partially qualified names (so, has an interior dot) should never have been allowed to work, anywhere, not even for a day. once they existed, it should have been somebody's job to stomp them to death. for my part in these events, i apologize to one and all. in fairness, had we adopted the left-to-right presentation format preferred at first by our UK colleagues, we would have always had to write fully qualified names as .tld.sld.3ld, that is, the root dot would not have been optional, and there would have been no confusion between unqualified, partially qualified, and fully qualified domain names. or with a little bit of arm twisting at the right time in the right place, search lists could have been explicit, as in, if you want FOO.BAR to be looked up in the client's preferred local contexts, you'd write it as FOO.BAR.+ or similar. the presentation layer is where DNS shows its greatest design weaknesses. (just ask the IDN folks, they'll tell you.) vixie vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/14 7:40 PM, Andrew Sullivan wrote: On Thu, Sep 11, 2014 at 07:15:03PM -0700, Doug Barton wrote: If you want a text list of TLDs that *is* updated in real time, you can use this: https://data.iana.org/TLD/tlds-alpha-by-domain.txt Yes, but that's what's already in fact delegated, not what is about to (so it's the same as just getting the root zone, AFAICT). Right. I was responding to your comment about http://newgtlds.icann.org/en/program-status/delegated-strings not being updated in real time. The IANA list is updated at the same time a new string goes into the root zone. So like the list you mentioned, it contains the list of delegated strings, but IS actually updated in real time. Am I missing something here? Doug ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On Thu, Sep 11, 2014 at 07:48:27PM -0700, Doug Barton wrote: Am I missing something here? Only the point of the part of the message you elided in your response. Best regards, A -- Andrew Sullivan a...@anvilwalrusden.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/14 7:53 PM, Andrew Sullivan wrote: On Thu, Sep 11, 2014 at 07:48:27PM -0700, Doug Barton wrote: Am I missing something here? Only the point of the part of the message you elided in your response. Ok, so let's recap, to make sure I get the point. Because I like to, yaknow, learn stuff. :) 1. Joshua asks if there is a way to be notified of new TLDs coming online 2. I respond with the URL that addresses his concern 3. You respond with the same URL, plus pontification on various topics, including a list of already delegated TLDs that you point out is not updated in real time 4. I respond to say that if you want such a list of already-delegated TLDs that is updated in real time, the IANA has one 5. You respond, apparently to reiterate the point that this list contains the TLDs that have already been delegated, along with more pontification about the need for ICANN to publish 'Here's what we plan to delegate next,' without perhaps giving a time. Which, FWIW, is the exact content of the URL that I (and you) responded to Joshua with in the first place. Now, did I get all that right? Because I really want to benefit from your wisdom here. :) Doug ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
On 9/11/2014 8:22 PM, Mark Andrews wrote: In message 54125edc.6000...@redbarn.org, Paul Vixie writes: On 9/11/2014 7:08 PM, Mark Andrews wrote: ... I just wish I had been able to convince Paul to remove support for partially qualified names back when RFC 1535 came out. We knew then that they were a bad idea. ndots minimises the damage of using partially qualified names. It doesn't remove it. at the time (1993?) i felt it was best not to break anybody's existing configuration. that seems insane now. The configuration is *already* broken. If you are depending upon partially qualified names then they are a time bomb waiting to happen. you know what would be cool is if i still used MH and could usefully search my e-mail archives to prove that paul vixie and mark andrews just now (2014-09-11) repeated almost verbatim a debate we had some time in 1993 or 1994. it would not just be funny, but perhaps also depressing, and it would save time. i believe that the next line of dialogue from this play is: vixie: your definition of 'break' is academic, mine is practical. right now the people who are using unqualified names are getting work done and they are not calling me to report bugs in the BIND resolver. if i make the change you are suggesting, they stop getting work done and they will look me up in WHOIS and call my phone. like i said this seems insane now. mark was right, we should have broken the bad stuff as early as possible. Today the resolver does as entered, if it has a period then applies the search list. If ndots != 0 and it has a period then it applies the search list and then as is. Unqualified search list then as is. Note the search list is always applied and it continues on NODATA, SERVFAIL which is also a security issue. NXDOMAIN should be the *only* result which moves to the next search list element. If a zone in the search list is broken, then fix it. Users can type fully qualified names to work around the issue and configuration files should only ever have fully qualified names. those words, the resolver, may not mean any more what you think they mean. the most widely cloned and forked resolver logic on the internet remains BIND 4's. not even the libbind (now netresolv) logic comes close to the footprint of that old crappy pre-ndots logic. all growth will be in the form of either dnsget API or ietf getaddrinfo / getnameinfo. i feverishly hope that both of these will subscribe to the logic described in: https://www.icann.org/en/system/files/files/sac-064-en.pdf if your resolver is to be used as a stub by any system library anywhere, i hope it will subscribe to the SAC064 logic. The best long term solution is if it has a period, try as is. If it does not have a period append search list against the DNS. localhost matches against /etc/hosts or becomes a explict exception. you sound like a man about to author an internet draft for IETF DNSOP. Iterim if it has a period, try as is. If ndots != 0 then try search list then try as is. If it does not have a period append search list against the DNS. localhost matches against /etc/hosts or becomes a explict exception. Ndots is a explict trigger for broken behaviour. yeah i don't think that anything like ndots could be standardized or should be implemented at this point in time. ndots was my suggested workaround for the EDU.COM problem, and shows that more review was needed. vixie ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Hearing first complains about failing internal resolving due to .prod TLD
In message 541271ba.2000...@redbarn.org, Paul Vixie writes: On 9/11/2014 8:22 PM, Mark Andrews wrote: In message 54125edc.6000...@redbarn.org, Paul Vixie writes: On 9/11/2014 7:08 PM, Mark Andrews wrote: ... I just wish I had been able to convince Paul to remove support for partially qualified names back when RFC 1535 came out. We knew then that they were a bad idea. ndots minimises the damage of using partially qualified names. It doesn't remove it. at the time (1993?) i felt it was best not to break anybody's existing configuration. that seems insane now. The configuration is *already* broken. If you are depending upon partially qualified names then they are a time bomb waiting to happen. you know what would be cool is if i still used MH and could usefully search my e-mail archives to prove that paul vixie and mark andrews just now (2014-09-11) repeated almost verbatim a debate we had some time in 1993 or 1994. it would not just be funny, but perhaps also depressing, and it would save time. i believe that the next line of dialogue from this play is: vixie: your definition of 'break' is academic, mine is practical. right now the people who are using unqualified names are getting work done and they are not calling me to report bugs in the BIND resolver. if i make the change you are suggesting, they stop getting work done and they will look me up in WHOIS and call my phone. like i said this seems insane now. mark was right, we should have broken the bad stuff as early as possible. It isn't impossible. Emit warnings whenever a partially qualified name matches and syslog / EventLog it. WARNING: The partially qualified name '%s' resulted in a search list match. The use of partially qualified names is a unsafe practice. Fix your configuration to use the fully qualified name '%s'. Linux developers do stuff like this for deprecated system calls where the user has zero control. Here the user can correct the configuration / behaviour. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] Botnets, botnets everywhere
2014-09-11 21:02 GMT+04:00 Cathy Almond cat...@isc.org: On 11/09/2014 13:38, Peter Andreev wrote: Hello, We run a public resolver and a few days ago I noticed a lot of very weird queries, like the following: 16:11:41.450794 IP 217.195.66.253.37426 62.76.76.62.53: 42580+ A? swfjwvtkhqx.www.feile.com. (47) 16:11:41.450796 IP 91.209.124.75.50584 62.76.76.62.53: 37269+ [1au] A? izhsccxedub.www.feile666.com. (57) For the total amount of SLDs of 11, the only common in those queries are random labels on the left side. One of those SLDs is an online-shop, another is online-casino, so I concluded that our resolver is being used to bombard NSes of corresponding SLDs with queries. I'd like to ask the respected community, how do you detect and protect against such activity? Will RRL help me if all suspected queries come with random qname? Thank you in advance. There's a lot of this about. We did awhile back wonder if it was botnet-related, but I've not (yet) seen any persuasive evidence that it is. Our current thinking (based on evidence from some of our customers, and also from Nominum's analysis presented at the Warsaw DNS-OARC workship earlier this year) that the majority of these recent query spates are intended as an attack on the domain (e.g. feile.com) or the nameserver hosting it. Once overwhelmed with query traffic, the DNS servers cease responding, or only respond sporadically. These authoritative server admins may also be deploying RRL to protect themselves too - but from your perspective, they're non-responding either way (with one exception - which is if they respond with the TC bit set to encourage a TCP-based query instead). I agree that it looks like an attack on DNS infrastructure. However yesterday I read a discussion between members of CENTR security workgroup and met a very interesting opinion that domains in question are belong to one of the biggest asian betting sites and it may be their way to identify clients or something so. Despite that I've counted these queries as malicious and moved all these domains to blocklist. The attackers appear to be making use of open resolvers (lists of which are readily available) presumably in order to ensure that the queries come from a whole range of clients, and possibly to provide another level of obscurity for the actual source. If you're running a public recursive server, you may be seeing the queries both directly and indirectly. The indirect queries are likely being forwarded to you by other servers or by insecure CPE devices that proxy queries to port 53 on their WAN interface by forwarding them to the ISP provider's DNS servers. There are quite a few things you can do to alleviate the problem, including limiting access to your open resolvers, identifying and blocking traffic that is coming to you via broken CPE devices, and identifying and communicating with admins of open resolvers that are forwarding to you. The main problem is the automatic identifying. Currently I see no relations between different packets and have to cope with the problem by hand. Other techniques include making yourself authoritative for the domains that are under attack (you can usually identify them from the traffic - some admins have scripted solutions), and/or using a DNS RPZ domain to block the queries - although you need a version of DNS RPZ that includes the qname-wait-recurse option that you'll want to set to 'yes' to make the rewriting occur prior to iteration. This is what I actually did. If you're running BIND, we're working on some new recursive rate limiting techniques that we're quite keen to get more exposure to - they involve rate-limiting queries to servers that are becoming non-responsive. I presented on the most recent evolution of those earlier this week at UKNOF29 in Belfast (they were earlier aired at IETF90 in Toronto and some useful suggestions taken on-board). https://indico.uknof.org.uk/conferenceOtherViews.py?view=standardconfId=31 See Nominum's session at 9:40 with further analysis of the traffic, and mine at 10:00 on various mitigation techniques. Hope this helps? (And also, I'm very keen to hear/see evidence of other causes and sources of this type of query traffic) Cathy ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs -- Is there any problem Exterminatus cannot solve? I have not found one yet. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
