Subject: Re: [ietf-dkim] Timeouts retrieving keys from ietf.org

From: Jim Fenton <[email-masked]>
Date: Tue, 08 Oct 2013 11:04:42 -0700

On 9/15/13 12:59 PM, John R. Levine wrote:
> Traceroutes confirm that it's dead, I sent a note to ietf-action.
>
> On Sun, 15 Sep 2013, Jim Fenton wrote:
>
>> Slightly off-topic for this list, but the dkim-ops mailing list seems to
>> be dormant...
>>
>> I'm getting a fair number of DKIM key lookup failures from ietf.org.  I
>> have run into this on two different mail servers with independent
>> resolver configurations, so I'm inclined to think the problem is not on
>> my end:
>>
>> Sep  7 12:58:19 v2 opendkim[1019]: r87JwCmq008446: key retrieval failed
>> (s=ietf1, d=ietf.org): timeout DNS query for `ietf1._domainkey.ietf.org'
>>
>> If anyone else is seeing this, let me know and I'll report it.  My
>> theory is that their DNS servers are struggling to respond to many key
>> requests after sending out signed messages to large mailing lists. The
>> TTL is 30 minutes, which may be too short.
>>
>> -Jim
>>
It turns out that the glue records for ietf.org were messed up. I sent a
note to ietf-action on that, and they have at least worked around the
problem (see below). I'm surprised Network Solutions had this problem.

I haven't seen any key retrieval timeouts since they implemented this.

On 10/5/13 7:51 AM, Glen via RT wrote:
> Jim -
>
> We've hit a wall with Network Solutions, and have been unable to get
> past it.  For reasons they cannot explain, they are unable to modify, or
> allow us to modify, the glue record for "ns0.ietf.org".
>
> Because this is clearly a problem, and one which will become much worse
> when we start moving to upgraded colocation facilities in the coming
> weeks, I have simply modified the domain itself to point to the more
> correct "ns0.amsl.com" record.  This is a record which we -do- have
> control over, and which is correctly configured on all levels.
>
> This should resolve any issues you've encountered, not to mention
> preventing future issues that might be very bad.
>
> I apologize for this confusion.  Thanks for bringing this to our
> attention, and thanks for your patience on this matter.  Please feel
> free to contact us if you require anything further at any time.
>
> Regards,
> Glen
> Glen Barney
> IT Director
> AMS (IETF Secretariat)
>
>
> On Tue Sep 24 14:09:49 2013, stevey wrote:
>> Hi Jim,
>>
>> Unfortunately Network Solutions seem unable to correct the record for
>> us, and we are escalating this to IETF leadership and Network Solutions'
>> Corporate level.
>>
>> This process could take a week or two but we will stay on top of it and
>> let you know when we get things fixed.
>>
>> Best regards,
>> Steve
>>
>> On Mon Sep 23 09:04:09 2013, stevey wrote:
>>> Hi Jim,
>>>
>>> We are working to get the glue records resolved, however, Network
>>> Solutions is having to escalate our request.  They have informed us it
>>> may take 2-3 days to correct this.  We'll keep you informed and let
>>> you know as soon as this is fixed.
>>>
>>> Best regards,
>>> Steve
>>>
>>> On Thu Sep 19 22:02:05 2013, [email-masked] wrote:
>>>> I have been getting intermittent errors retrieving IETF's DKIM key
>>>> records from DNS, and upon investigation I ran into the what seems
> to be
>>>> an inconsistency in the "glue" records for the ietf.org domain.
>>>>
>>>> According to:
>>>>
>>>> http://www.dnssy.com/report.php?q=ietf.org
>>>>
>>>> the glue record for ns0.ietf.org says its address is 12.22.58.2 rather
>>>> than 64.170.98.2, which is the address given in the domain's zone
> file.
>>>> Please let me know when this is corrected (or if it's not really an
>>>> error) and I will check to see if there are further errors retrieving
>>>> DKIM keys.
>>>>
>>>> -Jim
>>>>

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "John Levine" <[email-masked]>
Date: 10 Oct 2013 01:40:04 -0000

> I'm surprised Network Solutions had this problem.

Unfortunately, I'm not.  The current incarnation of NSI is a pale
shadow of its former self, a subsidiary of web.com that as far as I
can tell exists primarily to provide one-stop registration and
hosting, along with business from the surprisingly large number of
people who still don't understand that NSI and Verisign separated a
decade ago.

They've had some high profile DNS screwups recently, like this one:

http://blogs.cisco.com/security/hijacking-of-dns-records-from-network-solutions/

I can think of several registrars who are notably more competent and
charge less.