Subject: [dns-dir] .eg DNS

From: Thomas Narten <[email-masked]>
Date: Mon, 31 Jan 2011 11:58:16 -0500

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

---

From: Roy Arends <[email-masked]>
Date: Mon, 31 Jan 2011 17:28:43 +0000

> being authoritative. I.e., its stops serving  the data.

That is correct. The 140 days translates to June 16th (calculated from the day the routes changed). Gerhard Winkler (univie.ac.at) informed me he keeps a local copy of the zone in case he needs to change from Secondary to Primary.

> decrement TTLs over time as the zone becomes closer to "expiring". 

Indeed. both secondaries are responding, and the primary (frcu.eun.eg) is unreachable. Meanwhile, the registry itself is unreachable as well.

> indefinitely, we have 140 days (from Friday) before DNS queries stop

Correct.

> worry about at this point from a DNS perspective?

I've looked at various TLD zones to look for nameservers hosted from EG (in both the EG namespace as well as IP addresses unreachable due to routes) and there are a few non specific. (No eg. nameserver names in the co.uk or org.uk zones).

Hope this helps,

Roy

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 31 Jan 2011 20:16:36 +0100

> indefinitely, we have 140 days (from Friday) before DNS queries stop

Almost, operators of the individual nameservers may override the Expiry date and choose to serve data that they happen to have.  Note that that is a choice of the operators, not of ICANN IMHO. If you want to know what PSG.com would do you could ask Randy Bush.

> worry about at this point from a DNS perspective?

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.

--Olaf

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 31 Jan 2011 20:52:34 +0100

On Jan 31, 2011, at 8:20 PM, Joe Abley wrote:

> 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.
> 

Fair enough, but that is a bit of a coincidence. 

> 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).

Yes, my mail was more a hypothetical and something on which the board, or the staff may want to develop some guidelines.

Oh, not acting Unilaterally is obviously a very good guiding principle (stronger than a guide-line).

--Olaf (who thinks we are in violent agreement)