[dns-operations] DNSimple under attack?
Their website can't be reachable from my end. And one of my domains with them can't be resolved. Thanks. ___ 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] ccTLD operators
There are some people in the list,such as from denic, nic.fr, cnnic etc. Good evening. I am trying to get in touch with ccTLD operators across the world , to ask several questions regarding their operations. Can you please contact me off-list if you are able to help me ? ___ 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] The Largest Cyber Attack In History Has Been Hitting Hong Kong Sites
The obvious suspect behind the attacks is the Chinese government // This is just shame. Don't we have the rules to stop them? From the article: “There’s no technical solution that Cloudflare can create to solve this problem unless we re-architect the Internet.” I just love this kind of thinking! ___ 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] RBL alert: impending sh*tshow for rbl.orbitrbl.com
zoneedit was once owned by dotster, the mother-company of domain.com and mydomain.com. is it? As some of you may know, we recently took over ZoneEdit.com and it's customer base. ___ 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] Virgin Media (AS5089)
Can you talk what's the secret? :P Anyone from Virgin Media that is on this list mind sending me an email offline? I'd be interested to see one, too: an OFFLINE email... ;- ___ 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] Hello from the dns.watch project!
Thanks for the info. I have two another questions, 1st, does the .watch tld owned by your company fully? 2nd, do you provide the security filter as OpenDNS does? 在 2014-08-16 06:34，German Hoeffner 写道： -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello everyone! First of all, a short introduction of myself: My name is German Hoeffner and I'm working for companies in the hosting sector. One of those companies is Ideal-Hosting which I am also a shareholder of. Ideal-Hosting UG (haftungsbeschränkt) is a hosting company located in Germany, which has (fortunately) very strict data privacy law. We're involved in many projects which we think the Internet community benefits of. I've recently been informed that dns.watch was discussed on this mailing list some time ago. I went through the archive thread (which you can find here: https://lists.dns-oarc.net/pipermail/dns-operations/2014-July/011948.html) and noticed that there are some open questions. Q: Who is operating DNS.WATCH? A: Ideal-Hosting is operating the DNS.WATCH Project as a not-for-profit project. It's important to us that the users and people who are interested in the project know who is running DNS.WATCH and that they can reach us in case any they have any questions or issues with our service. Q: Why are the resolvers slow from certain locations? A: While we're operating an excellent network in Frankfurt, Germany, we're not anycasted (yet). We already have specific plans on anycasting the resolvers and it should go live later this year. However, we will continue to offer explicit Germany only resolver addresses, as this is important for some people. Q: Why is DNSSEC not enabled on dns.watch A: It is currently not possible for us to set DNSSEC (DS) entries with the domain api of our registrar. As soon as this is possible, we'll start using DNSSEC. Thanks again for all the suggestions and comments on the first thread. We take all feedback serious, as you can see we've now enabled mail on the domain as well. Questions, anyone? - -- Sincerely, German Hoeffner DNS.WATCH Administrator -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT7osCAAoJEFXDutqVVa2xJc0H/212nUv/ddkWmfQsfW6xdFAB SHDMML20UmJEcsvp4lUzIWhSZeohyn0LTFEe4OsyfJNsYWN2tsk0ZCKyRbRdOrmK PdoLurxkezO18W7wJwJZeVkFBP/1UEMHG5E/uMnUXPPUEstDOJkZulkPV/NxSMqt CFf7YG6g0Z3nWLH9NZ85oOlcHAS0XnFVz5ej1BoymqVYSMQtO6OPtpXZ3RYwsCz2 J6er2njYK+1bY5AtJGYIbPEhT4xvlquuPbKHsqPPoQTas2ZzRx41surcPff5XIgi Ifi5ghfP240wgOImoJcIHODyjk7+YMukm5iWR3nUYgF+6GfQMt7hnAVmNr/4i6A= =l9QH -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] Hello from the dns.watch project!
Do you know what're the special skills for running an open resolver server? If running it with BIND, just change the recursion option to yes and it will resolve all the clients' domain request. So besides the two items below: #1, setup anycast networks #2, build anti-ddos system what're the left stuff? sorry I have some experience on running auth-dns servers, but have no experience for open-dns cache. Thanks. what exactly do you mean if the .watch tld is owned by our company? .watch tld is provided by Donuts (http://www.donuts.co/). dns.watch is the domain name we rent, that is correct. Owning a top-level-domain would be way too expensive for a small Bavarian company ;) We do not provide any security filters. We want to offer resolvers where we do not alter any part of the records. Some people requested this, but right now we do not feel comfortable with it. Hope I could answer your questions. Let me know if you have more. ___ 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] rdata out of range
Thanks all. I have forgot that. 于 2014-4-30 18:07, Chris Dent 写道: The number you're using is greater than 4294967295, it's too big. The serial is a unsigned 32-bit integer field, yours will only fit if you up that 64-bit which will kind of break the published packet structure rather a lot. Cheers, Chris On 30 April 2014 11:03, Ken Peng kp...@terra.com mailto:kp...@terra.com wrote: Hi, I update the SOA with nsupdate but got the error: [20140430175917] 30-Apr-2014 17:59:17.384 dns_rdata_fromtext: buffer-0xb61c2bbc:1: near '800099': out of range invalid rdata format: out of range syntax error 800099 is the serial I setup. The server is linux 32bit OS. nameserver is BIND9.7. Can you tell what's wrong? Thanks. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net mailto:dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs 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] most of root NS and com's NS fail from here
于 2014-4-29 12:21, David Conrad 写道: Ken, On Apr 28, 2014, at 7:43 PM, Ken Peng kp...@terra.com wrote: Recent days I found most of the root nameservers, and com/net's nameservers can't work from here. When accessing to them I always got timeout. If you're querying from inside China, probably the first thing you should check is to see if the root server IP addresses you're querying match the following list (a-m): a.root-servers.net. - 198.41.0.4 b.root-servers.net. - 192.228.79.201 c.root-servers.net. - 192.33.4.12 d.root-servers.net. - 199.7.91.13 e.root-servers.net. - 192.203.230.10 f.root-servers.net. - 192.5.5.241 g.root-servers.net. - 192.112.36.4 h.root-servers.net. - 128.63.2.53 i.root-servers.net. - 192.36.148.17 j.root-servers.net. - 192.58.128.30 k.root-servers.net. - 193.0.14.129 l.root-servers.net. - 199.7.83.42 m.root-servers.net. - 202.12.27.33 I checked them, all seem correct. a.root-servers.net. 579835 IN A 198.41.0.4 b.root-servers.net. 579834 IN A 192.228.79.201 c.root-servers.net. 579843 IN A 192.33.4.12 d.root-servers.net. 579837 IN A 199.7.91.13 e.root-servers.net. 172815 IN A 192.203.230.10 f.root-servers.net. 579597 IN A 192.5.5.241 g.root-servers.net. 579591 IN A 192.112.36.4 h.root-servers.net. 579578 IN A 128.63.2.53 i.root-servers.net. 579587 IN A 192.36.148.17 j.root-servers.net. 579591 IN A 192.58.128.30 k.root-servers.net. 579599 IN A 193.0.14.129 l.root-servers.net. 172762 IN A 199.7.83.42 m.root-servers.net. 579603 IN A 202.12.27.33 and a.root-servers.net. - 2001:503:ba3e::2:30 b.root-servers.net. - c.root-servers.net. - 2001:500:2::c d.root-servers.net. - 2001:500:2d::d e.root-servers.net. - f.root-servers.net. - 2001:500:2f::f g.root-servers.net. - h.root-servers.net. - 2001:500:1::803f:235 i.root-servers.net. - 2001:7fe::53 j.root-servers.net. - 2001:503:c27::2:30 k.root-servers.net. - 2001:7fd::1 l.root-servers.net. - 2001:500:3::42 m.root-servers.net. - 2001:dc3::35 You then might want to do a traceroute to those IP addresses and see if it looks like they're going towards the right places (a little complicated given anycast routing, but if they all stay within China, you might be a bit suspicious). You then might want to try pinging those IP addresses to see the loss/latency stats. This is the traceroute info for one of the failed nameservers. $ traceroute h.root-servers.net traceroute to h.root-servers.net (128.63.2.53), 30 hops max, 60 byte packets 1 113.108.228.129 (113.108.228.129) 0.404 ms 0.886 ms 1.064 ms 2 121.14.46.93 (121.14.46.93) 0.475 ms 0.941 ms 1.227 ms 3 121.14.37.33 (121.14.37.33) 6.604 ms 6.958 ms 7.168 ms 4 121.14.37.6 (121.14.37.6) 0.369 ms 0.377 ms 0.393 ms 5 121.14.50.13 (121.14.50.13) 1.569 ms 1.615 ms 1.694 ms 6 113.108.208.97 (113.108.208.97) 4.362 ms 3.704 ms 3.624 ms 7 (202.97.34.202) 2.973 ms 2.976 ms 2.972 ms 8 202.97.61.234 (202.97.61.234) 1.429 ms 1.421 ms 1.297 ms 9 202.97.52.154 (202.97.52.154) 161.854 ms 161.380 ms 161.363 ms 10 202.97.49.158 (202.97.49.158) 157.784 ms 157.338 ms 157.326 ms 11 218.30.54.198 (218.30.54.198) 255.352 ms 255.432 ms 255.425 ms 12 los-edge-05.inet.qwest.net (67.14.22.130) 251.492 ms los-edge-05.inet.qwest.net (67.14.22.106) 256.656 ms los-edge-05.inet.qwest.net (67.14.22.130) 251.350 ms 13 65-126-18-214.dia.static.qwest.net (65.126.18.214) 360.808 ms 360.171 ms 360.426 ms 14 143.56.244.2 (143.56.244.2) 258.023 ms 254.128 ms 254.172 ms 15 ap-1-1-1-nd.level3-lax.core.dren.net (140.6.244.1) 249.144 ms 248.882 ms 249.567 ms 16 np-5-1-1-nd.sandiego.core.dren.net (140.6.0.1) 359.050 ms 358.964 ms 359.087 ms 17 138.18.190.89 (138.18.190.89) 349.903 ms 349.947 ms 349.974 ms 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * The ping info: $ ping -c 3 h.root-servers.net PING h.root-servers.net (128.63.2.53) 56(84) bytes of data. 64 bytes from 128.63.2.53: icmp_seq=1 ttl=45 time=355 ms 64 bytes from 128.63.2.53: icmp_seq=2 ttl=45 time=356 ms 64 bytes from 128.63.2.53: icmp_seq=3 ttl=45 time=257 ms --- h.root-servers.net ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 21549ms rtt min/avg/max/mdev = 257.609/323.121/356.333/46.325 ms Thanks! I am from China, ISP telecom. Can you tell what happens? Probably not definitively without more information... Regards, -drc ___ 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] most of root NS and com's NS fail from here
于 2014-4-29 17:27, Dave Warren 写道: Beyond what the others said, IPv4 or v6? I vaguely recall some global routing problems on IPv6 with at least a couple root server... This might complicate matters. All our servers don't have IPv6 configured. So the queries were going with v4. ___ 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] most of root NS and com's NS fail from here
Thanks for all your helps. The dig for version.bind and hostname.bind sometime works, sometime not. as you see: pyh@dwdns153:~$ dig txt chaos version.bind @h.root-servers.net ; DiG 9.6.1-P2 txt chaos version.bind @h.root-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21537 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT NSD 4.0.3 ;; Query time: 257 msec ;; SERVER: 128.63.2.53#53(128.63.2.53) ;; WHEN: Wed Apr 30 09:02:23 2014 ;; MSG SIZE rcvd: 52 pyh@dwdns153:~$ dig txt chaos hostname.bind @h.root-servers.net ; DiG 9.6.1-P2 txt chaos hostname.bind @h.root-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 29675 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;hostname.bind. CH TXT ;; ANSWER SECTION: hostname.bind. 0 CH TXT 003.nzy.h.root-servers.org ;; Query time: 256 msec ;; SERVER: 128.63.2.53#53(128.63.2.53) ;; WHEN: Wed Apr 30 09:02:37 2014 ;; MSG SIZE rcvd: 70 pyh@dwdns153:~$ pyh@dwdns153:~$ pyh@dwdns153:~$ dig txt chaos version.bind @h.root-servers.net +short ; DiG 9.6.1-P2 txt chaos version.bind @h.root-servers.net +short ;; global options: +cmd ;; connection timed out; no servers could be reached pyh@dwdns153:~$ pyh@dwdns153:~$ pyh@dwdns153:~$ dig txt chaos version.bind @h.root-servers.net +short ; DiG 9.6.1-P2 txt chaos version.bind @h.root-servers.net +short ;; global options: +cmd ;; connection timed out; no servers could be reached And this is the mtr info for h.root-servers.net: pyh@dwdns153:~$ mtr h.root-servers.net --report HOST: dwdns153.dns.yt.yygamedev.c Loss% Snt Last Avg Best Wrst StDev 1. 113.108.228.129 40.0%100.5 0.5 0.5 0.8 0.1 2. 121.14.46.93 10.0%100.5 0.5 0.5 0.5 0.0 3. 121.14.37.33 0.0%102.7 3.3 1.6 7.2 1.9 4. 121.14.37.6 0.0%100.4 0.4 0.3 0.7 0.1 5. 121.14.50.13 0.0%101.5 2.3 0.9 4.3 1.2 6. 113.108.208.970.0%104.8 3.9 1.6 5.9 1.5 7. 202.97.34.202 0.0%101.1 1.5 0.9 5.2 1.3 8. 202.97.61.234 0.0%102.1 1.6 1.3 2.2 0.3 9. 202.97.52.154 0.0%10 148.6 149.7 147.7 151.3 1.3 10. 202.97.49.158 0.0%10 151.5 150.7 148.6 151.8 1.2 11. 218.30.54.198 0.0%10 174.9 183.0 174.9 209.5 9.7 12. los-edge-05.inet.qwest.net0.0%10 169.8 175.9 169.8 180.5 3.4 13. 65-126-18-214.dia.static.qwe 0.0%10 172.7 179.4 172.7 186.4 4.5 14. 143.56.244.2 0.0%10 160.5 173.9 160.5 192.2 11.6 15. ap-1-1-1-nd.level3-lax.core. 0.0%10 160.7 167.6 160.1 173.4 4.7 16. np-5-1-1-nd.sandiego.core.dr 0.0%10 177.9 185.6 177.9 195.3 5.0 17. 138.18.190.8910.0%10 163.8 172.2 163.8 178.3 4.4 18. 138.18.190.114 10.0%10 163.2 163.4 163.1 164.8 0.5 19. 128.63.2.53 10.0%10 171.2 180.3 171.2 185.4 4.2 Regards. Ken 于 2014-4-30 5:16, Warren Kumari 写道: Oh, sure, I totally agree NSID/hostname.bind etc. will be very helpful. My experience is that if these query hit a masquerading root node, you mostly won't get an answer, by either no ANSWER section or empty string in ANSWER section. ___ 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] about the rName with dot
Hi, For the rName in SOA, when the username has a dot,shall it be converted to \.? For example, user's email is john.sm...@rackspace.com, so it appears in SOA as john\.smith.rackspace.com, is it? Is there a live example for this kind of rName? Thanks. ___ 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] most of root NS and com's NS fail from here
Hi, Recent days I found most of the root nameservers, and com/net's nameservers can't work from here. When accessing to them I always got timeout. These are the test info for root NS: $ dig . ns +short |sort |while read LINE;do if dig . soa @$LINE /dev/null 21;then echo $LINE OK;else echo $LINE fail;fi;done a.root-servers.net. OK b.root-servers.net. fail c.root-servers.net. OK d.root-servers.net. fail e.root-servers.net. OK f.root-servers.net. OK g.root-servers.net. OK h.root-servers.net. fail i.root-servers.net. OK j.root-servers.net. fail k.root-servers.net. OK l.root-servers.net. fail m.root-servers.net. OK (5 o 13 failed) These are the test info for com's NS: $ dig com ns +short |sort |while read LINE;do if dig com soa @$LINE /dev/null 21;then echo $LINE OK;else echo $LINE fail;fi;done a.gtld-servers.net. fail b.gtld-servers.net. fail c.gtld-servers.net. OK d.gtld-servers.net. fail e.gtld-servers.net. OK f.gtld-servers.net. fail g.gtld-servers.net. OK h.gtld-servers.net. OK i.gtld-servers.net. fail j.gtld-servers.net. fail k.gtld-servers.net. fail l.gtld-servers.net. fail m.gtld-servers.net. OK (8 of 13 failed) I am from China, ISP telecom. Can you tell what happens? Thanks. ___ 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] bind + client-subnet
On 2013-8-13 18:30, Jared Mauch wrote: I'm not sure how accurate this really is, but: http://www.cdnplanet.com/blog/which-cdns-support-edns-client-subnet/ Basically, it helps pass the client IP upstream so the CDN can make a better guess to which cluster to direct you to, instead of the query-source IP of the recursive they are talking to. but how to implement that? since local DNS server always has caching. ___ 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] bind + client-subnet
On 2013-8-13 11:57, Jared Mauch wrote: Does anyone know if BIND supports the client-subnet option, or do I need to seek another recursive resolver for this? it does seem there are some patches, but I'm not sure if this is something others have experimented with, e.g.: http://wilmer.gaa.st/edns-client-subnet/ We operate a large recursive resolver infrastructure and I'm thinking the users will be best served with this option set to be directed to local CDN caches. Wanted to ask about what others were doing before I went to our dns group. Do you mean the BIND views? It has been there for many years. http://www.zytrax.com/books/dns/ch7/view.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] what type of attack is this?
On 2013-8-9 16:09, Steven Carr wrote: Is there a reason why your nameservers are allowing those IP addresses to query you? (and thus query waig8.com) i.e. are you supposed to be running an open resolver on those nameservers? Hi, My nameservers are auth-only. that means we are the auth-servers for that domain. Regards. ___ 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
