Subject: Re: [dns-dir] .eg DNS

From: Joe Abley <[email-masked]>
Date: Mon, 31 Jan 2011 14:20:51 -0500

On 2011-01-31, at 14:16, Olaf Kolkman wrote:

> In a DNSSEC enabled environment serving an Expired zone would not be possible after the signatures expired. I that case IANA could take an action by pulling the DS. I currently believe that in geo-political turmoil as we see now IANA should never do that. In the case of natural disaster the case may be slightly different, but that seems something where IANA could make bilateral service level agreements about.

ICANN has staff in Egypt (Baher Esmat) who currently has internet access via modem and international phone call to Europe, and has a satellite phone for voice communications. I suspect a trusted communications channel to the EG manager could be arranged via Baher if it turned out it was needed to authenticate a root zone change for EG.

ICANN does not act unilaterally in these cases, but takes direction from TLD managers.

(Note also that EG is not signed, so DNSSEC signature expiration is not a problem in this particular case. For a signed zone, though, signature expiration is probably a greater concern than zone expiry).

Joe

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 31 Jan 2011 17:35:17 +0000

This makes some sense operationally.  Long expirys were once common in
TLD zone SOAs hosted in parts of the world with iffy connectivity, for
exactly the reason that sometimes slaves would lose connectivity to
masters and you didn't want the zone to go lame while things got
sorted out-- less for policy reasons than because, IIRC, the form of
client/app bad behavior resulting from having an auth server hand out
SERVFAILs was deemed worse than timeouts from a successful resolution
when the underlying resource was unreachable.

On Mon, Jan 31, 2011 at 11:58:16AM -0500, Thomas Narten wrote:
> There have obviously been lots of discussions about the situation in
> Egypt. Internet essentially doesn't work in Egypt, and there is no
> connectivity into Egypt from outside.
> 
> >From a DNS perspective, what are the key things that we need to pay
> attention to? (I'm trying to get the facts straight in my
> conversations with the ICANN board, to be sure people are acting on
> facts, rather than assumptions).
> 
> My understanding is that when DNS names for .eg requested, root
> servers respond with an NS RR pointing to the authoritative servers
> for eg. I.e.,:
> 
> > [cichlid] ~ 121 >dig -t soa eg. @l.root-servers.net
> > 
> > ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> -t soa eg. @l.root-servers.net
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60919
> > ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4
> > ;; WARNING: recursion requested but not available
> > 
> > ;; QUESTION SECTION:
> > ;eg.				IN	SOA
> > 
> > ;; AUTHORITY SECTION:
> > eg.			172800	IN	NS	ns5.univie.ac.at.
> > eg.			172800	IN	NS	rip.psg.com.
> > eg.			172800	IN	NS	frcu.eun.eg.
> > 
> > ;; ADDITIONAL SECTION:
> > ns5.univie.ac.at.	172800	IN	A	193.171.255.77
> > rip.psg.com.		172800	IN	A	147.28.0.39
> > frcu.eun.eg.		172800	IN	A	193.227.1.1
> > rip.psg.com.		172800	IN	AAAA	2001:418:1::39
> > 
> > ;; Query time: 44 msec
> > ;; SERVER: 199.7.83.42#53(199.7.83.42)
> > ;; WHEN: Mon Jan 31 11:33:10 2011
> > ;; MSG SIZE  rcvd: 176
> 
> The root zone will serve this data indefinitely, until such time as
> the zone file is updated. This only happens as a result of an explicit
> IANA action, going through NTIA and VRSN.  Consequently, there is no
> implication to root servers w.r.t. events in Egypt. They will continue
> serving the current data indefinitely.
> 
> At the next level, the SOA returned by authoritative servers is as
> follows:
> 
> [cichlid] ~ 122 >dig -t soa eg @RIP.PSG.COM.
> 
> > ; <<>> DiG 9.7.2-P3-RedHat-9.7.2-5.P3.fc14 <<>> -t soa eg @RIP.PSG.COM.
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50526
> > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
> > ;; WARNING: recursion requested but not available
> > 
> > ;; QUESTION SECTION:
> > ;eg.				IN	SOA
> > 
> > ;; ANSWER SECTION:
> > eg.			604800	IN	SOA	FRCU.EUN.eg. Postmaster.FRCU.EUN.eg. 2010100421 15000 7200 12096000 86400
> > 
> > ;; AUTHORITY SECTION:
> > eg.			604800	IN	NS	RIP.PSG.COM.
> > eg.			604800	IN	NS	NS5.UNIVIE.AC.AT.
> > eg.			604800	IN	NS	FRCU.EUN.eg.
> > 
> > ;; ADDITIONAL SECTION:
> > FRCU.EUN.eg.		86400	IN	A	193.227.1.1
> > 
> > ;; Query time: 132 msec
> > ;; SERVER: 147.28.0.39#53(147.28.0.39)
> > ;; WHEN: Mon Jan 31 11:36:30 2011
> > ;; MSG SIZE  rcvd: 161
> 
> Key thing of note. The SOA "expire" time is 12096000 seconds, which
> translates to 140 days. If a secondary cannot contact the primary
> within this time, the zone is considered old and the secondary stops
> being authoritative. I.e., its stops serving  the data.
> 
> Also, when responding to general RR queries, authoritative servers
> always return the TTL associated with the RRset. I.e., they do not
> decrement TTLs over time as the zone becomes closer to "expiring". 
> 
> Thus, assuming that the primary servers for eg remain unreachable
> indefinitely, we have 140 days (from Friday) before DNS queries stop
> resolving.
> 
> Do I have the above details right? Is there anything else to note or
> worry about at this point from a DNS perspective?
> 
> Thomas