ICANN Public Comment period related to DNS Root Zone KSK closes October 5, 2015
(Apologies for duplicates of this) ICANN has an open Public Comment period on work relating to changing the Root Zone's DNSSEC Public KSK. The formal Public Comment process closes October 5, 2015. For further details, consult this URL: https://www.icann.org/public-comments/root-ksk-2015-08-06-en The title of the Public Comment period is: Design Team Review of Plan for DNS Root Zone KSK Change URLs of note, all of these are found from the URL above. The draft report in English: https://www.icann.org/en/system/files/files/root-zone-ksk-rollover-plan-dra ft-04aug15-en.pdf There are also versions of the report in 6 other languages. And the comments forum: http://forum.icann.org/lists/comments-root-ksk-06aug15/ smime.p7s Description: S/MIME cryptographic signature
Live-streaming the Root Zone Key-Signing Key Ceremony 22
FYI, (Apologies if you see duplicates of this message.) ICANN, as the IANA Functions Operator, will be live-streaming the Root Zone Key-Signing Key Ceremony (number 22) on Thursday, August 13. The main ceremony that day is scheduled to begin at 2000UTC. (This is an activity related to DNSSEC.) For more information about the event see: https://www.iana.org/dnssec/ceremonies/22 On Thursday there will be two cermonies as listed on that web page. The first ceremnoy will rotate cryptographic officer duties, basically, a change in some of the trusted community representatives participating in the key ceremonies. The second ceremony (the main) will feature the introduction of two new Hardware Security Modules. This is the ceremony that will start at 2000 UTC. Please see the above link for more information. The live-streaming link is at the bottom of the page. (https://icann.adobeconnect.com/kskceremony) smime.p7s Description: S/MIME cryptographic signature
Solicitation for Statements of Interest regarding Root KSK Rollover
(I am not sure if this appeared on this list before, so just to be sure, perhaps yet another posting of this announcement:) ICANN, as the IANA functions operator, in cooperation with Verisign as the Root Zone Maintainer and the National Telecommunications Information Administration (NTIA) as the Root Zone Administrator, together known as the Root Zone Management (RZM) partners, seek to develop a plan for rolling the DNS root zone key-signing key (KSK). The KSK is used to sign the root zone zone-signing key (ZSK), which in turn is used to DNSSEC-sign the Internet’s root zone. The Root Zone Partners are soliciting five to seven volunteers from the community to participate in a Design Team to develop the Root Zone KSK Rollover Plan (“The Plan”). These volunteers along with the RZM partners will form the Design Team to develop The Plan. Individuals interested in volunteering approximately 5 hours per week for the Design Team should consult the announcement: https://www.icann.org/en/system/files/files/ksk-soi-11dec14-en.pdf and submit their Statement of Interest to ksk-rollover-...@icann.org no later than January 16, 2015.
Re: How our young colleagues are being educated....
Last time I taught, I lectured (senior-level 3-credit elective) on calculating the efficiency of Ethernet and why it was no good above 10Mbps. On Dec 23, 2014, at 15:29, Mike Hammett na...@ics-il.net wrote: At the time, though, Ethernet belonged within a building. If you were wanting to connect multiple buildings together, bust out those T1s. Fortunately for society, I *stopped* teaching in 1998. Hope it was soon enough.
Re: Other things in the Baltimore area
On Oct 6, 2014, at 17:02, Jeff Shultz jeffshu...@sctcweb.com wrote: The BO Train Museum is a must-see stop for anyone interested in railroads - http://www.borail.org/Collections.aspx Following the trains NANOG theme - one can visit the site of the Howard Street Tunnel fire: http://en.wikipedia.org/wiki/Howard_Street_Tunnel_fire or as NANOG saw it: https://www.nanog.org/mailinglist/mailarchives/old_archive/2001-07/msg00351.html loved this follow up: https://www.nanog.org/mailinglist/mailarchives/old_archive/2001-07/msg00370.html (I’m amazed how well the list is archived - this was over 13 years ago.) I was downtown at the time and they were telling every one that the air was toxic, close your windows…and me stuck in traffic in my convertible with a worn out (torn) roof.
Re: ddos attacks
On Dec 18, 2013, at 18:12, cb.list6 wrote: I am strongly considering having my upstreams to simply rate limit ipv4 UDP. It is the simplest solution that is proactive. Recently it's been said that when a protocol is query/response (like DNS), willingly suppressing responses might be as harmful as passing all the traffic. This comes from a presentation at October's DNS-OARC workshop: https://indico.dns-oarc.net//getFile.py/access?contribId=4resId=0materialId=slidesconfId=1 This is a what is possible in theory presentation, said to help you set your expectation whether this is a true threat or not. The underlying message is that while a querier is waiting for a response, there is a window of vulnerability in which a forged response might be accepted. If the responder elects not to respond, they increase the (time) duration of that window. While smart rate limiting exhibits benefits I suspect simple rate limiting might have some undesirable consequences. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Why is it that people who fear government monitoring of social media are surprised to learn that I avoid contributing to social media?
RE: RIRs give out unique addresses (Was: something has a /8! ...)
At 9:56 -0500 9/20/12, Naslund, Steve wrote: I suppose that ARIN would say that they do not guarantee routability because they do not have operational control of Internet routers. ARIN does not provide transit - how could they guarantee or even just provide best-effort routability? However, Wouldn't you say that there is a very real expectation that when you request address space through ARIN or RIPE that it would be routable? Perhaps, but that is misguided. ARIN, et.al. don't get involved in peering or block lists or firewall configuration guides or hurricane forecasting or ... anything else that bars reachability. If I decide to unilaterally block traffic from your address range, ARIN, et.al., can't do anything about it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars!
ccTLD operators do not rule, was Re: Concern about ...
At 16:38 -0800 3/10/12, Owen DeLong wrote: The more telling fallacy here that really speaks to the heart of why I am dismayed and disappointed by ICANN's management of the whole TLD mess is the idea that a CCTLD is the property of a TLD operator to begin with. This is not true. First, there is the ccTLD itself - it is an organization that is recognized has having legitimate claim to the country code. These do change at times. Then there is the ccTLD operator. Some ccTLDs own and operate and some do out source the technical operations, sometimes just DNS, sometimes everything (e.g., the database). When out sourcing, the ccTLD owner makes contractural demands of the operator. If the ccTLD requires an in-country DNS presence that is easily arranged by the operator. (The operator reflects the cost in the price.) With the growing awareness of the role of the Internet, ccTLDs do not let the operator do their thing. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 2012...time to reuse those 1984 calendars!
Re: Dnssec and ptr records
At 9:13 -0500 10/18/11, Eric J Esslinger wrote: Are we supposed to setup signing for reverse dns zones? To the DNS, a zone is a zone. The terms forward and reverse as zone adjectives were invented by humans. ;) The high-level view of signing the reverse zones is the same as for forward zones. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Vote for the word of the day: Paparazzi - father that constantly takes photos of the baby Corpureaucracy - The institution of corporate red tape
cox.net in NoVa IPv6 engineer sought
I have some questions wrt IPv6 workings...can someone from cox contact me privately? Thanks in advance, -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 I'm overly entertained.
Godwin was here ... was Re: Rogers Canada using 7.0.0.0/8
In reference to recent messages: I tend to doubt it. I'm pretty sure the DoD has the phone number to the FBI. Yes, but the FBI just shows up with several agents in dark sunglasses and suits and surgically removed senses of humor. Bad news, but it still doesn't ruin your day like a Predator drone suddenly appearing outside your window... http://en.wikipedia.org/wiki/Godwin%27s_Law -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Now, don't say I'm always complaining. Wait, that's a complaint, isn't it?
Re: trouble with .gov dns?
At 18:53 +0200 5/3/11, Florian Weimer wrote: * David Conrad: On May 2, 2011, at 10:19 PM, Florian Weimer wrote: I would go even further---the DO bit is not about DNSSEC at all. Err, yes it is. I know you think it is, but you're wrong if you look at the overall protocol. This is becoming a thread-to-the-death over a general weakness in the DNS protocol. (Realizing this mailing list is NANOG, not an IETF one.) Like it or not, versioning and negotiation are poor-to-non-existent in DNS. What's happening here is a document author (David) meant one thing and implementations (e.g., BIND) interpreting the document another way. It doesn't matter that David is right (in that he meant it another way, and the way is what the WG meant), it more matters that the ship has sailed on fixing this in implementations. And frankly, the fix isn't that important in retrospect because what the implementers did is actually ok, we can and we do live nicely with it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Me to infant son: Waah! Waah! Is that all you can say? Waah? Son: Waah!
Re: Root Zone DNSSEC Deployment Technical Status Update
At 7:53 -0700 7/16/10, Leo Bicknell wrote: Perhaps you could explain why the keys are being made available in formats that, as far as I can tell, no nameserver software on the planet uses? (My guess:) There's no standard input format for name servers, especially regarding configuration information. The problem isn't (just) that the root anchor isn't in the format for any name server, the problem is that name servers can't read the formats given. If you want it for BIND, for example, ISC would be the place to get it in the trusted-keys syntax. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh.
Re: Reverse DNS Question
At 15:37 -0500 4/20/10, Larry Sheldon wrote: To minimize unwarranted hassle, if you will have email senders, spend some time looking into the requirements. I don't think there are any RFC or other authoritative standards in the matter. This is as close as the IETF has come to a document. http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 That document has been expired for 3 years, meaning, no one has updated it, no one has tried to get a steering committee broad review (IESG approval), etc. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same?
Re: 192.0.0.0/24
At 8:24 -0700 3/30/10, Leo Vegoda wrote: 192.0.0.0/24 is used for the IANA IPv4 Special Purpose Address Registry: For the record, there's an RFC dedicated to that range (which Leo co-edited): http://www.rfc-editor.org/in-notes/rfc5736.txt -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 New pithy statement under construction...
Policy feedback - was Re: Denic (.de) blocking 6to4
At 13:26 +0100 2/11/10, Igor Ybema wrote: Ok, policy is policy and we should not complain. No, really, policies should be examined and questioned. Having been in policy meetings, unless the operations crowd openly questions and gives feed back, the meetings are just wastes of time. However, I'm asking your opinions about this policy. That's the right first step. (Note: no commentary on 6to4 in this, I'm not familiar enough with it.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
Re: Who has AS 1712?
At 0:32 -0500 11/24/09, Jon Lewis wrote: Lots of ASNs have been assigned but aren't visible in the global table. And not all global networks (needing unique numbering) connect to the global public internet. At 8:36 +0100 11/24/09, Stephane Bortzmeyer wrote: Yes, very good idea. And to check the BGP public routing table also (belts and suspenders...) That's a good check, but not sufficient. When last we fixed an ASN registration, the check showed that other ASN's we had were not seen in that table. We just mentioned they are used on another inter-network and passed. Kinda like belts and suspenders but let's make sure the fly is shut too. ;) At 15:58 +0900 11/24/09, Randy Bush wrote: owned resources may not be announced or visible universally. Right...or maybe in a different universe. existing data sources deeply suck. rir source data are in different formats, owner identies are not even unique in one rir (how many names does goog have in arin?), let alone coordinated across rirs, much historical data is missing, ... This is why an inter-registry database inspection tool is needed. The traditional one is WhoIs - which as Randy mentions is too vague in content. (The WhoIs spec only says something about TCP to port 43...and nothing about the query/response formats.) A tool like IRIS is on the shelf that could be a platform from which to build something better. Checking the global public internet tables is a good first step, but that's not all that is needed. Such a step only gives credence to uniqueness, but it doesn't guarantee it. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
Re: What DNS Is Not
At 0:32 + 11/10/09, bmann...@vacation.karoshi.com wrote: not being Paul, its rude of me to respond - yet you posted this to a public list ... so here goes. Why do you find your behaviour in your domains acceptable and yet the same behaviour in others zones to be a Bad Thing... Not being anyone who has posted on this thread on a public list... I agree that the rules for what is acceptable in the operations of DNS zones vary from zone to zone. This is because of the different relationships between the zone administrator and the entities represented in the zone and the different relationships between the zone administrator and the relying parties. (Im just going to pick on one reason.) For the root zone or aTLD (which themselves have differences) the relationships tend to be global, multilingual, etc. Stability and coherence here are vital for operations, because as you know being in operations really means handling outages. Once a problem pops up, it might take a while (hours, days) to go from report to root cause analysis to long-term fix. If the root and TLDs have lots of bells and whistles then, well, this is hard, so the root and TLDs are kept simple. For a zone lower in the stack assumptions are different. Generally speaking, the zone represents a single entity (a government agency, store, school) who will have a varying degree of active management of what is in the zone. They may even be able to roll back to some point in time and see what is in the zone. On-the-fly response generation is even acceptable because they can see what mislead someone, etc. (if they zone is properly run). And by on-the-fly I am including wildcards generated answers, calculated answers or answers based on source of the request, etc., and other demographics or current load measures. As far as relying parties, think about who do I call? when I can't get through. They have two obvious choices - their ISP or the organization they want to reach. Calls will end up with the ISP if the issue is high up in the zone, calls might get to the organization if the problems are lower in the tree. (Because perhaps they got to the main web page but not to the department page.) This is just one reason why it's reasonable to manage different DNS zones differently, why the rules don't apply the same everywhere. There are many other reasons. But this is a public list. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
A DNSSEC irony
At 15:53 -0700 8/5/09, Douglas Otis wrote: DNSSEC UDP will likely become problematic. dotORG (.org) is DNSSEC signed now. nanog.org is DNSSEC signed now. Still getting mail on the list saying DNSSEC UDP will be a problem... (from some commercial's punch line) ...priceless Continuing, This might be due to reflected attacks, fragmentation related congestion, or packet loss. The same issues (related to the size of DNSSEC answers) are also true for the size of IPv6 answers ( RR) and the size of ENUM (NAPTR RR) answers. I.e., the perceived issues related to stuffing data into larger (than 512B) datagrams aren't unique to DNSSEC. So, if you are paranoid about DNSSEC now, don't worry, there's more to be paranoid about around the corner. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction.
Re: hat tip to .gov hostmasters
At 15:30 + 9/22/08, [EMAIL PROTECTED] wrote: data. We never finished the discussion on fail/open fail/closed wrt DNSSEC. And I'd bet a dollar we never will finish that discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
Re: Why *can* cached DNS replies be overwritten?
At 11:31 -0500 8/11/08, Jack Bates wrote: Leo Bicknell wrote: Authorities are updated all the time. There are thousands of these cache overwrites with new, more up to date info every day. The problem is, it's not trustworthy. In the original definition of DNS, there were no or almost no dynamic changes. The protocol wasn't built for that. The result is all of the old sacred texts are written in a context that everything is static (for as least as long as the TTL). The modern operation of the DNS is more dynamic. It isn't a case that the protocol today cannot be (more) dynamic (than the founding engineers thought) but that all of the documented texts upon wish we today base arguments are written along the old think lines. So when we get into a battle of RFCs vs. best current practices the two sides are not speaking the same language. The DNS can be more dynamic by liberalizing it's ability to learn new data. It's a sliding curve - more liberal means accepting more stuff, some of which might be the garbage we don't want. The choice is between tight and unbending versus dynamic and less trustworthy. The goal is to strike the right balance. It is possible for a protocol to do what DNS does and also have secure updates. But the DNS as it is in the RFCs, lacks a real good foundation for extension. We can do something, but we will probably never get to the final goal. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
Re: OT: www.Amazon.com down?
At 23:00 -0400 6/6/08, Andrew D Kirch wrote: Paul Ferguson wrote: Are you looking in the right place? :-) %dig www.imdb.com ; DiG 9.3.2 www.imdb.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 924 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.imdb.com. IN A ;; ANSWER SECTION: www.imdb.com. 4400IN CNAME us.imdb.com. us.imdb.com.4 IN CNAME us.dd.imdb.com. us.dd.imdb.com. 16 IN A 72.21.206.70 ... Odd, I'm seeing it now. Couldn't see it for 20-30 minutes. Andrew I saw this problem late last night too. The problem was downstream in the CNAME chain. I was able to access IMDB by using us.dd.imdb.com (http://us.dd.imdb.com) while the www.imdb.com address was (in some sense of the word) broken. My local recursor got a SERVFAIL for www.imdb.com and inserted a redirection page for it. Using dig +trace at the time I could work my way around the issue. I bet the recursor got most of the way there but couldn't get the A record or something. As it was very late for me, I didn't try to debug it. Just had a burning question about I movie I had just seen. ;) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Never confuse activity with progress. Activity pays more.
