[dns-operations] Looking for a public blackhole/sinkhole IP address
I'm trying to find out if it exists a public IP address which is a black hole, swallowing every packet sent to it. I can do that on my network but I'm wondering if it already exists somewhere, may be as an anycasted service (AS112-style). The idea is to delegate some domain names to unresponsive name servers (deleting the domain name is less efficient, since the negative TTL is smaller than the delegation TTL). It must work from everywhere on the Internet. 127/8 does not (the packets are not dropped but delivered to the resolver itself when it will try to follow the delegation). Same thing for RFC 1918 (there are often such addresses in the local network). I was thinking of non-routed addresses like 198.18.0.0/15 or 203.0.113.0/24 but it's not their normal use. AFAIK, there are no public sinkholes IPv4 addresses. For IPv6, there is 100::/64 but it is only internal, there is no public 100::/64 service. ___ 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] REMINDER Re: Call for Participation -- ICANN DNSSEC Workshop at ICANN 52
Call for Participation -- ICANN DNSSEC Workshop at ICANN 52 in Singapore The DNSSEC Deployment Initiative and the Internet Society Deploy360 Programme, in cooperation with the ICANN Security and Stability Advisory Committee (SSAC), are planning a DNSSEC Workshop at the ICANN 52 meeting on 11 February 2015 in Singapore. The DNSSEC Workshop has been a part of ICANN meetings for several years and has provided a forum for both experienced and new people to meet, present and discuss current and future DNSSEC deployments. For reference, the most recent session was held at the ICANN meeting in Los Angeles on 15 October 2014. The presentations and transcripts are available at: http://la51.icann.org/en/schedule/wed-dnssec. We are seeking presentations on the following topics: 1. DNSSEC activities in Asia For this panel we are seeking participation from those who have been involved in DNSSEC deployment in Asia and also from those who have not deployed DNSSEC but who have a keen interest in the challenges and benefits of deployment. In particular, we will consider the following questions: What can DNSSEC do for you? What doesn't it do? What are the internal tradeoffs to implementing DNSSEC? What did you learn in your deployment of DNSSEC? We are interested in presentations from both people involved with the signing of domains and people involved with the deployment of DNSSEC-validating DNS resolvers. 2. Potential impacts of Root Key Rollover Given many concerns about the need to do a Root Key Rollover, we would like to bring together a panel of people who can talk about what the potential impacts may be to ISPs, equipment providers and end users, and also what can be done to potentially mitigate those issues. In particular, we are seeking participation from vendors, ISPs, and the community that will be affected by distribution of new root keys. We would like to be able to offer suggestions out of this panel to the wider technical community. If you have a specific concern about the Root Key Rollover, or believe you have a method or solution to help address impacts, we would like to hear from you. 3. New gTLD registries and administrators implementing DNSSEC With the launch of the new gTLDs, we are interested in hearing from registries and operators of new gTLDs about what systems and processes they have implemented to support DNSSEC. As more gTLDs are launched, is there DNSSEC-related information that can be shared to help those launches go easier? 4. Guidance for Registrars in supporting DNSSEC The 2013 Registrar Accreditation Agreement (RAA) for registrars and resellers requires them to support DNSSEC from January 1, 2014. We are seeking presentations discussing: * What are the specific technical requirements of the RAA and how can registrars meet those requirements? * What tools and systems are available for registrars that include DNSSEC support? * What information do registrars need to provide to resellers and ultimately customers? We are particularly interested in hearing from registrars who have signed the 2013 RAA and have either already implemented DNSSEC support or have a plan for doing so. 5. APIs between the Registrars and DNS hosting operators One specific area that has been identified as needing focus is the communication between registrars and DNS hosting operators, specifically when these functions are provided by different entities. Currently, the communication, such as the transfer of a DS record, often occurs by way of the domain name holder copying and pasting information from one web interface to another. How can this be automated? We would welcome presentations by either registrars or DNS hosting operators who have implemented APIs for the communication of DNSSEC information, or from people with ideas around how such APIs could be constructed. 6. Implementing DNSSEC validation at Internet Service Providers (ISPs) Internet Service Providers (ISPs) play a critical role by enabling DNSSEC validation for the caching DNS resolvers used by their customers. We have now seen massive rollouts of DNSSEC validation within large North American ISPs and at ISPs around the world. We are interested in presentations on topics such as: * What does an ISP need to do to prepare its network for implementing DNSSEC validation? * How does an ISP need to prepare its support staff and technical staff for the rollout of DNSSEC validation? * What measurements are available about the degree of DNSSEC validation currently deployed? * What tools are available to help an ISP deploy DNSSEC validation? * What are the practical server-sizing impacts of enabling DNSSEC validation on ISP DNS Resolvers (ex. cost, memory, CPU, bandwidth, technical support, etc.)? 7. The operational realities of running DNSSEC Now that DNSSEC has become an operational norm for many registries, registrars, and ISPs, what have we learned about how we manage DNSSEC? What is the best practice
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
On Wed, 26 Nov 2014 15:25:47 +0100 Stephane Bortzmeyer bortzme...@nic.fr wrote: I was thinking of non-routed addresses like 198.18.0.0/15 or 203.0.113.0/24 but it's not their normal use. AFAIK, there are no public sinkholes IPv4 addresses. For IPv6, there is 100::/64 but it is only internal, there is no public 100::/64 service. Hi Stephane, There is not a well known netblock for the purpose you seek. We've floated the idea of setting up a sinkhole with our new UTRS project as an alternative to just using a traditional next-hop RTBH and some people have expressed interest in doing this so we may yet offer it. While we might not be able to donate a prefix for general use, we might be willing to also host such a sinkhole people can point any unwanted traffic to. If this is of any interest I'd like to know. We might need some hosting help around the globe if it takes off, but this is the sort of thing we'd be well positioned to run and willing to do if there was sufficient community interest. 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] Looking for a public blackhole/sinkhole IP address
We have such an IP address in our backbone but don't publish it. I suppose someone could ask for an allocation for this purpose from a local RIR and this could be done for that whole range. Jared Mauch On Nov 26, 2014, at 9:25 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: I'm trying to find out if it exists a public IP address which is a black hole, swallowing every packet sent to it. I can do that on my network but I'm wondering if it already exists somewhere, may be as an anycasted service (AS112-style). The idea is to delegate some domain names to unresponsive name servers (deleting the domain name is less efficient, since the negative TTL is smaller than the delegation TTL). It must work from everywhere on the Internet. 127/8 does not (the packets are not dropped but delivered to the resolver itself when it will try to follow the delegation). Same thing for RFC 1918 (there are often such addresses in the local network). I was thinking of non-routed addresses like 198.18.0.0/15 or 203.0.113.0/24 but it's not their normal use. AFAIK, there are no public sinkholes IPv4 addresses. For IPv6, there is 100::/64 but it is only internal, there is no public 100::/64 service. ___ 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] Looking for a public blackhole/sinkhole IP address
On Wed, 26 Nov 2014, Stephane Bortzmeyer wrote: I'm trying to find out if it exists a public IP address which is a black hole, swallowing every packet sent to it. I was thinking of non-routed addresses like 198.18.0.0/15 or 203.0.113.0/24 but it's not their normal use. AFAIK, there are no public sinkholes IPv4 addresses. For IPv6, there is 100::/64 but it is only internal, there is no public 100::/64 service. http://tools.ietf.org/html/rfc6598 defines 100.64.0.0/10 Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. One exception to this paragraph's proscription is in the case of business relationships, such as hosted CGN services. When running a single DNS infrastructure, Service Providers MUST NOT include Shared Address Space in zone files. When running a split DNS infrastructure, Service Providers MUST NOT include Shared Address Space in external-facing zone files. So you should be fine to use it :) It is the responsibility of your ISP to filter it when you leak it out of your network. 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] Looking for a public blackhole/sinkhole IP address
On Wed, Nov 26, 2014 at 03:25:47PM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 25 lines which said: I'm trying to find out if it exists a public IP address which is a black hole, swallowing every packet sent to it. A possible example is blackhole.webpagetest.org/72.66.115.13 http://blog.patrickmeenan.com/2011/10/testing-for-frontend-spof.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] Looking for a public blackhole/sinkhole IP address
Stephane Bortzmeyer wrote: I was thinking of non-routed addresses like 198.18.0.0/15 or 203.0.113.0/24 but it's not their normal use. AFAIK, there are no public sinkholes IPv4 addresses. For IPv6, there is 100::/64 but it is only internal, there is no public 100::/64 service. There is some precedent for using TEST-NET addresses to shed DNS queries. RFC 6471 §3.4 suggests such a procedure when shutting down DNSBLs, and there is at least one DNSBL that uses it (list.dsbl.org). -- Robert Edmonds ___ 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] Bind v6 TCP listen?
Is there some specific configuration magic that I’m missing to make bind listen
to TCPv6 sockets?
Looking at what it’s doing via lsof it seems to not be listening to v6/tcp:
named 909 named 20u IPv4 24571 0t0 TCP
204.42.254.5:domain (LISTEN)
named 909 named 21u IPv4 28306 0t0 TCP
127.0.0.1:rndc (LISTEN)
named 909 named 512u IPv4 24570 0t0 UDP
204.42.254.5:domain
named 909 named 513u IPv4 24570 0t0 UDP
204.42.254.5:domain
named 909 named 514u IPv6 28319 0t0 UDP
[2001:418:3f4::5]:domain
named 909 named 515u IPv6 28319 0t0 UDP
[2001:418:3f4::5]:domain
My configuration is fairly straightforward, including manual listen-on
segments, e.g.:
listen-on { 204.42.254.5; };
listen-on-v6 { 2001:418:3f4::5; };
- Jared
___
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] Looking for a public blackhole/sinkhole IP address
On 2014-11-26 16:42, Stephane Bortzmeyer wrote: On Wed, Nov 26, 2014 at 04:33:37PM +0100, Jeroen Massar jer...@massar.ch wrote a message of 15 lines which said: What about putting those zones/nameservers in DNS RPZ? I don't get it. RPZ is for resolvers. Your first line: The idea is to delegate some domain names to unresponsive name servers With RPZ you can overrule those on the nameserver or domain level. Greets, Jeroen ___ 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] Looking for a public blackhole/sinkhole IP address
On Nov 26, 2014, at 10:13 AM, Paul Wouters p...@nohats.ca wrote: http://tools.ietf.org/html/rfc6598 defines 100.64.0.0/10 Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. One exception to this paragraph's proscription is in the case of business relationships, such as hosted CGN services. When running a single DNS infrastructure, Service Providers MUST NOT include Shared Address Space in zone files. When running a split DNS infrastructure, Service Providers MUST NOT include Shared Address Space in external-facing zone files. So you should be fine to use it :) That’s certainly not the intent/purpose of the block of space any more than hard-coding 10.0.0.1 or some other answer like 1.1.1.1 or 1.2.3.4. - Jared ___ 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] Looking for a public blackhole/sinkhole IP address
On 26 Nov 2014, at 09:25, Stephane Bortzmeyer bortzme...@nic.fr wrote: I'm trying to find out if it exists a public IP address which is a black hole, swallowing every packet sent to it. I can do that on my network but I'm wondering if it already exists somewhere, may be as an anycasted service (AS112-style). You could use exactly the AS112 nameservers for this. They are deployed for the purpose of attracting junk. They won't give good responses to queries, but you don't care about that. 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
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
On Wed, Nov 26, 2014 at 12:46 PM, Jared Mauch ja...@puck.nether.net wrote: On Nov 26, 2014, at 10:13 AM, Paul Wouters p...@nohats.ca wrote: http://tools.ietf.org/html/rfc6598 defines 100.64.0.0/10 Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. One exception to this paragraph's proscription is in the case of business relationships, such as hosted CGN services. When running a single DNS infrastructure, Service Providers MUST NOT include Shared Address Space in zone files. When running a split DNS infrastructure, Service Providers MUST NOT include Shared Address Space in external-facing zone files. So you should be fine to use it :) That’s certainly not the intent/purpose of the block of space any more than hard-coding 10.0.0.1 or some other answer like 1.1.1.1 or 1.2.3.4. N. not 1.2.3.4: route-viewssho ip bgp 1.2.3.4 BGP routing table entry for 1.2.3.0/24, version 60 Paths: (35 available, best #27, table default) Not advertised to any peer Refresh Epoch 1 6453 15169 66.110.0.86 from 66.110.0.86 (66.110.0.86) Origin IGP, localpref 100, valid, external rx pathid: 0, tx pathid: 0 What's wrong with 127.0.0.1? It makes it clear what the intent is, and you don't get a much more distributed sinkhole than that... If there really is a use case, let's try and get a block allocated, and encourage folk to anycast - null0 for this. I'm kinda leery of using the AS112 addresses themselves, because the target of this is likely to be DoS attacks and: A: AS112 folk might not really be expecting to be hit with a few hundred gig of garbage (yet) and B: some ISP will nail up the routes to null, and mess up the AS112 customers. W - Jared ___ 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 -- 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
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
On 11/26/14 6:25 AM, Stephane Bortzmeyer wrote: The idea is to delegate some domain names to unresponsive name servers (deleting the domain name is less efficient, since the negative TTL is smaller than the delegation TTL). What problem are you actually trying to solve here? Is this an AFNIC thing? ___ 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 v6 TCP listen?
At Wed, 26 Nov 2014 12:37:57 -0500,
Jared Mauch wrote:
Is there some specific configuration magic that I’m missing to make
bind listen to TCPv6 sockets?
[...]
My configuration is fairly straightforward, including manual
listen-on segments, e.g.:
listen-on { 204.42.254.5; };
listen-on-v6 { 2001:418:3f4::5; };
I realize I'm at risk of teaching my grandmother to suck eggs, but
reckon you must be dealing with something which is either really
obscure or hidden in plain sight, so here goes ...
I'ld expect that to be enough, unless there's a typo in the address.
I have for some reason
listen-on-v6 { all; };
It might be worth checking whether this makes a difference.
Best regards,
Niall O'Reilly
___
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] Looking for a public blackhole/sinkhole IP address
On 26 Nov 2014, at 14:06, Warren Kumari war...@kumari.net wrote: What's wrong with 127.0.0.1? It makes it clear what the intent is, and you don't get a much more distributed sinkhole than that... I'm always wary of using 127.0.0.1 for anything that doesn't really mean you should talk to yourself. Without a comprehensive knowledge of the impact, you don't know what you're blowing up. If there really is a use case, let's try and get a block allocated, and encourage folk to anycast - null0 for this. https://github.com/ableyjoe/draft-jabley-well-known-sinkhole Needs text. Not submitted. Co-authors welcome. 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
Re: [dns-operations] Bind v6 TCP listen?
On Nov 26, 2014, at 3:48 PM, Niall O'Reilly niall.orei...@ucd.ie wrote:
At Wed, 26 Nov 2014 12:37:57 -0500,
Jared Mauch wrote:
Is there some specific configuration magic that I’m missing to make
bind listen to TCPv6 sockets?
[...]
My configuration is fairly straightforward, including manual
listen-on segments, e.g.:
listen-on { 204.42.254.5; };
listen-on-v6 { 2001:418:3f4::5; };
I realize I'm at risk of teaching my grandmother to suck eggs, but
reckon you must be dealing with something which is either really
obscure or hidden in plain sight, so here goes ...
I'ld expect that to be enough, unless there's a typo in the address.
I have for some reason
listen-on-v6 { all; };
It might be worth checking whether this makes a difference.
Thanks everyone. Looks like this is actually a bug in bind, or the one
packaged with FC21 (at least).
With any it seems to do the right thing:
named 909 named 20u IPv4 24571 0t0 TCP
204.42.254.5:domain (LISTEN)
named 909 named 21u IPv4 28306 0t0 TCP
127.0.0.1:rndc (LISTEN)
named 909 named 22u IPv4 18812144 0t0 TCP
204.42.254.5:domain-217.21.61.8:21683 (ESTABLISHED)
named 909 named 23u IPv6 18810485 0t0 TCP *:domain
(LISTEN)
named 909 named 512u IPv4 24570 0t0 UDP
204.42.254.5:domain
named 909 named 513u IPv4 24570 0t0 UDP
204.42.254.5:domain
named 909 named 514u IPv4 18809462 0t0 UDP *:13642
named 909 named 516u IPv6 18810484 0t0 UDP *:domain
named 909 named 518u IPv6 18810484 0t0 UDP *:domain
I’ll have to do some more testing later, back to family time.
- Jared
___
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 v6 TCP listen?
On 11/26/14 1:17 PM, Ted Cooper wrote: I have the same thing, along with a note to myself that listening on a single address does not seem to work. What version of named, on what OS? ___ 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] Looking for a public blackhole/sinkhole IP address
On Wed, Nov 26, 2014 at 04:10:07PM -0500, Joe Abley wrote: On 26 Nov 2014, at 14:06, Warren Kumari war...@kumari.net wrote: What's wrong with 127.0.0.1? It makes it clear what the intent is, and you don't get a much more distributed sinkhole than that... I'm always wary of using 127.0.0.1 for anything that doesn't really mean you should talk to yourself. Without a comprehensive knowledge of the impact, you don't know what you're blowing up. If there really is a use case, let's try and get a block allocated, and encourage folk to anycast - null0 for this. https://github.com/ableyjoe/draft-jabley-well-known-sinkhole Needs text. Not submitted. Co-authors welcome. Would it make sense to also mention an probably seperate address which should generate host unreachables? This should most likely be rate limited and probably tcp only or something. For certain scenarios a quick nothing here could be useful E.g. sending smtp backscatter to a sink-hole or botnet command and control server. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital 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] Looking for a public blackhole/sinkhole IP address
On 26 Nov 2014, at 17:05, Florian Lohoff f...@zz.de wrote: On Wed, Nov 26, 2014 at 04:10:07PM -0500, Joe Abley wrote: On 26 Nov 2014, at 14:06, Warren Kumari war...@kumari.net wrote: What's wrong with 127.0.0.1? It makes it clear what the intent is, and you don't get a much more distributed sinkhole than that... I'm always wary of using 127.0.0.1 for anything that doesn't really mean you should talk to yourself. Without a comprehensive knowledge of the impact, you don't know what you're blowing up. If there really is a use case, let's try and get a block allocated, and encourage folk to anycast - null0 for this. https://github.com/ableyjoe/draft-jabley-well-known-sinkhole Needs text. Not submitted. Co-authors welcome. Would it make sense to also mention an probably seperate address which should generate host unreachables? This should most likely be rate limited and probably tcp only or something. My mental picture of a sinkhole is a hole into which things can be thrown without fear that they will come back out. What you're talking about sounds more like a volcano, which I would feel less happy standing next to with my bags of garbage. :-) For certain scenarios a quick nothing here could be useful E.g. sending smtp backscatter to a sink-hole or botnet command and control server. Can you explain in more detail? I don't think I'm getting it. If an end-user does something that triggers a packet to be sinkholed, who benefits if the sinkhole sources a packet back? This sounds like something that could be used to coordinate anonymous sinkhole backscatter towards arbitrary victims. Joe signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] ccTLD operators
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 ? thanks very much ___ 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] Looking for a public blackhole/sinkhole IP address
On Wed, Nov 26, 2014 at 4:10 PM, Joe Abley jab...@hopcount.ca wrote: On 26 Nov 2014, at 14:06, Warren Kumari war...@kumari.net wrote: What's wrong with 127.0.0.1? It makes it clear what the intent is, and you don't get a much more distributed sinkhole than that... I'm always wary of using 127.0.0.1 for anything that doesn't really mean you should talk to yourself. Without a comprehensive knowledge of the impact, you don't know what you're blowing up. If there really is a use case, let's try and get a block allocated, and encourage folk to anycast - null0 for this. https://github.com/ableyjoe/draft-jabley-well-known-sinkhole This thingie has many aspects that look a bunch like AS112 -- I'm wondering if it makes sense to also request an AS number for this. It's not strictly needed, but having fewer inconsistent origin routes is always nice. It also seems that (also like AS112), networks could do this in one of (at least) 3 ways: 1: They can spin up this route purely within their own network -- basically have one or more places where the route points at null0 / discard and *not announce it to peers / customers* or 2: announce to customers only or 3: be good citizens and announce it to everyone. 1 and 2 already exist, for RTBH (like you mention in the doc), they are just not anycasted. I wonder if we ask the IANA nicely if they'd assign 666.666.666.0/24 to.. oh, bugger The more people who do this, the more benefit there is - unfortunately this argument often doesn't work on the Internets, but still worth trying... Needs text. Not submitted. Co-authors welcome. I'm making some edits, will send a pull request in a bit. Specifically the guidance to network operators section, and I'll take an initial stab at a privacy considerations bit. I'm guessing that we are going to have somewhat of a fun time with the privacy / security implications bits. It won't be long till someone hits upon the idea of standing up a listener / server on one of these addresses. One would hope that the traffic that would arrive at a global sinkhole would be safe, but seeing as some of the uses for this would be to sink bad stuff, someone will want to measure how much bad stuff domain or malware XXX is generating - this will require looking at the bad stuff to disambiguate this bad stuff from that bad stuff, and now you have a bit of a mess... Perhaps this actually turns out to be a dangerous idea. W Joe -- 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
Re: [dns-operations] Looking for a public blackhole/sinkhole IP address
Joe Abley wrote: On 26 Nov 2014, at 14:06, Warren Kumari war...@kumari.net wrote: What's wrong with 127.0.0.1? It makes it clear what the intent is, and you don't get a much more distributed sinkhole than that... I'm always wary of using 127.0.0.1 for anything that doesn't really mean you should talk to yourself. Without a comprehensive knowledge of the impact, you don't know what you're blowing up. Indeed, some recursive DNS servers won't even attempt to send queries to 127.0.0.1 by default. (Unbound's do-not-query-localhost: yes default.) If there really is a use case, let's try and get a block allocated, and encourage folk to anycast - null0 for this. https://github.com/ableyjoe/draft-jabley-well-known-sinkhole Needs text. Not submitted. Co-authors welcome. A common method for dealing with unwanted traffic is to direct that traffic at nominated addresses within a network that are null-routed; that is, packets with such destination addresses are discarded silently by routers with a null route for that destination configured. These addresses are colloquially known as sinkholes, by analogy with the same term used in Physical Geography to describe a hole in the ground formed by some form of collapse of the surface layer, into which objects may fall and be lost forever. My colloquial understanding is that a blackhole discards traffic while a sinkhole is a routed network address which gathers information from the inbound packets. Some even use the term sinkhole to mean a network address that returns application-specific responses. E.g., the Conficker Working Group deployed HTTP sinkholes which listen on 80/tcp and capture HTTP requests from infected hosts. So, I would consider s/sinkhole/blackhole/g, at least. -- Robert Edmonds ___ 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] Looking for a public blackhole/sinkhole IP address
Warren Kumari wrote: This thingie has many aspects that look a bunch like AS112 -- I'm wondering if it makes sense to also request an AS number for this. It's not strictly needed, but having fewer inconsistent origin routes is always nice. It also seems that (also like AS112), networks could do this in one of (at least) 3 ways: 1: They can spin up this route purely within their own network -- basically have one or more places where the route points at null0 / discard and *not announce it to peers / customers* or 2: announce to customers only or 3: be good citizens and announce it to everyone. 1 and 2 already exist, for RTBH (like you mention in the doc), they are just not anycasted. I wonder if we ask the IANA nicely if they'd assign 666.666.666.0/24 to.. oh, bugger The more people who do this, the more benefit there is - unfortunately this argument often doesn't work on the Internets, but still worth trying... If one is trying to dispose of 250 million DNS requests per second [0] or 1Mr/s (mega-requests per second) [1], then you probably *don't* want the traffic to be routed to whoever happens to have announced it, or anywhere, really. That seems to be a much different use case (drop the traffic as quickly and universally as possible, minimizing collateral damage) from routing the traffic to something like a community sinkhole. [0] http://www.forbes.com/sites/parmyolson/2014/11/20/the-largest-cyber-attack-in-history-has-been-hitting-hong-kong-sites/ [1] https://la51.icann.org/en/schedule/mon-tech/presentation-dafa888-dos-attack-13oct14-en.pdf -- Robert Edmonds ___ 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
On Nov 26, 2014, at 3:01 PM, Matteo Brighi mat...@noip.co wrote: 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 ? There are various groups inside ICANN that might have the folks you want. There are various groups outside of ICANN that might as well. Two that come to mind are CENTR and APTLD. --Paul Hoffman ___ 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] Looking for a public blackhole/sinkhole IP address
If someone wanted to dispose of that volume of requests they could get assistance if they asked the right people. Jared Mauch On Nov 26, 2014, at 7:12 PM, Robert Edmonds edmo...@mycre.ws wrote: Warren Kumari wrote: This thingie has many aspects that look a bunch like AS112 -- I'm wondering if it makes sense to also request an AS number for this. It's not strictly needed, but having fewer inconsistent origin routes is always nice. It also seems that (also like AS112), networks could do this in one of (at least) 3 ways: 1: They can spin up this route purely within their own network -- basically have one or more places where the route points at null0 / discard and *not announce it to peers / customers* or 2: announce to customers only or 3: be good citizens and announce it to everyone. 1 and 2 already exist, for RTBH (like you mention in the doc), they are just not anycasted. I wonder if we ask the IANA nicely if they'd assign 666.666.666.0/24 to.. oh, bugger The more people who do this, the more benefit there is - unfortunately this argument often doesn't work on the Internets, but still worth trying... If one is trying to dispose of 250 million DNS requests per second [0] or 1Mr/s (mega-requests per second) [1], then you probably *don't* want the traffic to be routed to whoever happens to have announced it, or anywhere, really. That seems to be a much different use case (drop the traffic as quickly and universally as possible, minimizing collateral damage) from routing the traffic to something like a community sinkhole. [0] http://www.forbes.com/sites/parmyolson/2014/11/20/the-largest-cyber-attack-in-history-has-been-hitting-hong-kong-sites/ [1] https://la51.icann.org/en/schedule/mon-tech/presentation-dafa888-dos-attack-13oct14-en.pdf -- Robert Edmonds ___ 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] Looking for a public blackhole/sinkhole IP address
Stephane Bortzmeyer wrote: The idea is to delegate some domain names to unresponsive name servers (deleting the domain name is less efficient, since the negative TTL is smaller than the delegation TTL). What about specifying *no* nameservers? That is, delegating the domain name to a nonexistent nameserver name within an intentionally empty sacrificial zone with a lengthy negative TTL. -- Robert Edmonds ___ 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] ccTLD operators
Matteo can you inject a tad of context to help with this, like a little more detail and who you want to reach? (ie. marketing, legal, financial, policy, technical registration, dns resolution, security). 'Operations' is a pretty wide spread Jothan Frakes +1.206-355-0230 tel +1.206-201-6881 fax On Wed, Nov 26, 2014 at 5:13 PM, Ken Peng yhp...@orange.fr wrote: 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 ___ 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 v6 TCP listen?
In message 54764380.5000...@linuxwan.net, Ted Cooper writes:
On 27/11/14 06:48, Niall O'Reilly wrote:
I have for some reason
listen-on-v6 { all; };
It might be worth checking whether this makes a difference.
I have the same thing, along with a note to myself that listening on a
single address does not seem to work.
# IPv6 settings.
listen-on-v6 {
any;
# Unable to use specific address?? Confirmed.
# remo:edsp:ecif:i::cadd:ress;
};
query-source-v6 address remo:edsp:ecif:i::cadd:ress;
transfer-source-v6 remo:edsp:ecif:i::cadd:ress;
notify-source-v6 remo:edsp:ecif:i::cadd:ress;
The *-source-v6 all works as expected. I don't have any kind of
reference as to a bug entry or why it doesn't work.
There are some OS where named can't enumerate the IPv6 interfaces
usually due to stupid OS hacks which means the listen-on-v6 ACL
above has nothing to match against. What was wrong with providing
this information via the socket interface? Why put it in the
filesystem which then has to be duplicated when you are running
chroot'd?
That said this isn't the issue here as the process was bound on the
IPv6 UDP port. I suspect a accept() failure caused named to close
the socket or something else was listening on the TCP port when
named was started or ...
Mark
___
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] Bind v6 TCP listen?
On Nov 26, 2014, at 8:25 PM, Mark Andrews ma...@isc.org wrote: There are some OS where named can't enumerate the IPv6 interfaces usually due to stupid OS hacks which means the listen-on-v6 ACL above has nothing to match against. What was wrong with providing this information via the socket interface? Why put it in the filesystem which then has to be duplicated when you are running chroot’d? my use case is not chroot()’ed and it sounds like others have hit this as well. I’ve solved my immediate issue. Happy to troubleshoot more with another host elsewhere that doesn’t have 8.5k zones seeing queries so it’s easier to tell what occurred. (aside: really wish bind would launch faster when loading these zones, or background the loading of the zones and answer those it can). That said this isn't the issue here as the process was bound on the IPv6 UDP port. I suspect a accept() failure caused named to close the socket or something else was listening on the TCP port when named was started or ... This is possible, I will dig through logs looking for any relevant messages.. once I changed to any; things immediately resolved with a rndc reload. - Jared ___ 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] Looking for a public blackhole/sinkhole IP address
Robert Edmonds mailto:edmo...@mycre.ws Wednesday, November 26, 2014 4:59 PM What about specifying *no* nameservers? That is, delegating the domain name to a nonexistent nameserver name within an intentionally empty sacrificial zone with a lengthy negative TTL. experience and observation say that even with a lengthy negative ttl, there will be an awful lot of queries sent to the closest enclosing NS RRset for that nameserver name. there would also be a large volume of syslog traffic worldwide concerning this misconfiguration. something like AS112 would be best -- a real address that can be sunk or dunked by anyone. -- Paul 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] ccTLD operators
Thank you Jonathan, I figured since this is operations list, and going thru the archives of the list, I would only talk to engineers. I am looking to talk to engineering folks that run and operate ccTLDs technically, my questions around techniques of resiliency and stability of service. On Nov 26, 2014, at 5:23 PM, Jothan Frakes jot...@gmail.commailto:jot...@gmail.com wrote: Matteo can you inject a tad of context to help with this, like a little more detail and who you want to reach? (ie. marketing, legal, financial, policy, technical registration, dns resolution, security). 'Operations' is a pretty wide spread Jothan Frakes +1.206-355-0230 tel +1.206-201-6881 fax On Wed, Nov 26, 2014 at 5:13 PM, Ken Peng yhp...@orange.frmailto:yhp...@orange.fr wrote: There are some people in the list,such as from denic, nic.frhttp://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.netmailto: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] ccTLD operators
Manta- That should help the ones who would want to respond. There was a recent survey regarding the IANA transition -stuff- sent out to ccTLD administrators - I am asking the people who did the survey if A) it included info on operations like use of any cast and dnssec for example and B) if that was present, is it something they would share. Given sensitivity around sharing such data, I suspect they will say no to B. you will likely get individual responses from people on this list where there is interest in discussing it. Another option might be to reach out to the chair of the ccNSO and ask to present this request to their members during tech day at Singapore ICANN 52 in February or work with CENTR, APTLD, or other regionals on this. Hope that helps, - Jothan On Wednesday, November 26, 2014, Matteo Brighi mat...@noip.co wrote: Thank you Jonathan, I figured since this is operations list, and going thru the archives of the list, I would only talk to engineers. I am looking to talk to engineering folks that run and operate ccTLDs technically, my questions around techniques of resiliency and stability of service. On Nov 26, 2014, at 5:23 PM, Jothan Frakes jot...@gmail.com javascript:_e(%7B%7D,'cvml','jot...@gmail.com'); wrote: Matteo can you inject a tad of context to help with this, like a little more detail and who you want to reach? (ie. marketing, legal, financial, policy, technical registration, dns resolution, security). 'Operations' is a pretty wide spread Jothan Frakes +1.206-355-0230 tel +1.206-201-6881 fax On Wed, Nov 26, 2014 at 5:13 PM, Ken Peng yhp...@orange.fr javascript:_e(%7B%7D,'cvml','yhp...@orange.fr'); wrote: 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 javascript:_e(%7B%7D,'cvml','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 -- Jothan Frakes +1.206-355-0230 tel +1.206-201-6881 fax ___ 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] Looking for a public blackhole/sinkhole IP address
In message 547691e9.1080...@redbarn.org, Paul Vixie writes: Robert Edmonds mailto:edmo...@mycre.ws Wednesday, November 26, 2014 4:59 PM What about specifying *no* nameservers? That is, delegating the domain name to a nonexistent nameserver name within an intentionally empty sacrificial zone with a lengthy negative TTL. experience and observation say that even with a lengthy negative ttl, there will be an awful lot of queries sent to the closest enclosing NS RRset for that nameserver name. there would also be a large volume of syslog traffic worldwide concerning this misconfiguration. something like AS112 would be best -- a real address that can be sunk or dunked by anyone. -- Paul Vixie I would say CNAME/DNAME with a week long ttl to one of the non RFC 1918 or ULA default local zones but IANA has been tardy about getting the insecure delegations in place to break the DNSSEC chains of trust. That way default local zone aware recursive servers would answer negatively to the querier and you have a long lived cached record to slow the rate of queries from the recursive servers. e.g. 0.in-addr.arpa. 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
[dns-operations] cool idea regarding root zone inviolability
at: http://www.diplomacy.edu/policybriefs we see: http://www.diplomacy.edu/sites/default/files/DiploFoundation%20Policy%20Brief%20No%204%20WEB.pdf which contains: Policy suggestions1 • The Internet root zone should be inviolable at any time, wherever it may be located. • No state should have the jurisdiction to prescribe, adjudicate, or enforce policy over the Internet root zone. • The Internet root zone may only be modified through existing procedures or new ones that might be introduced in September 2015. • The inviolability of the Internet root zone should be based on customary law that recognises the consistent practice of no unilateral interference by the US authorities in the content of the Internet root zone. ...and more. -- Paul 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] cool idea regarding root zone inviolability
Thanks Paul, FWIW, I have been working on this for a while with the Diplo foundation, and I am happy to answer questions (and of course listen to concerns). Patrik On 27 nov 2014, at 05:26, Paul Vixie p...@redbarn.org wrote: at: http://www.diplomacy.edu/policybriefs we see: http://www.diplomacy.edu/sites/default/files/DiploFoundation%20Policy%20Brief%20No%204%20WEB.pdf which contains: Policy suggestions1 • The Internet root zone should be inviolable at any time, wherever it may be located. • No state should have the jurisdiction to prescribe, adjudicate, or enforce policy over the Internet root zone. • The Internet root zone may only be modified through existing procedures or new ones that might be introduced in September 2015. • The inviolability of the Internet root zone should be based on customary law that recognises the consistent practice of no unilateral interference by the US authorities in the content of the Internet root zone. ...and more. -- Paul 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
