> On 4 Jan 2018, at 10:54 am, Nick Hilliard <nick@xxxxxxxxxx> wrote:
>
> S Moonesamy wrote:
>> Hi Dave,
>> At 09:08 AM 02-01-2018, Dave Burstein wrote:
>>> today. The principles are simple; the implementation is demanding. So
>>> I'm asking engineers, "What technical systems must must be built to
>>> ensure robust interconnection, assuming everyone wants to work in good
>>> faith?"
>>
>> The proceedings of SIGCOMM 1988, 106-114, discuss about survivability in
>> the face of failure. That might be similar to the "robust
>> interconnection" which is mentioned above. Part of the message [1] is
>> about DNS. There is a 2006 document about that (SSAC 009).
>
> it would be important to be careful about language. "Interconnection"
> refers to IP layer connectivity, but this is a discussion about
> alternative DNS roots.
>
> The technical work on this was done in two tranches: the first works in
> the 1990s were a result of the AlterNIC saga, when BIND 4.9 was hardened
> against dns pollution from alternative servers. Until then, DNS
> poisoning from misconfigured and malconfigured DNS server had been an
> ongoing problem, but this formed a new baseline standard for handling
> cache pollution.
>
> The second major improvement was dnssec, which requires a single root
> per resolver. If Russia or anyone else sets up an alternative root, then
> dnssec-enabled resolution will fail for dnssec domains on other roots.
It requires that trust anchors be install for each of the namespaces so
that DNSSEC will work. Its a bit brittle but not impossible. If ICANN
was to remove .ru from the root you could restore validation by configuring
the validators to know about .ru DNSSEC key.
e.g. (for BIND/named)
managed-keys {
. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
ru. initial 257 3 8 "AwEAAcqaT0pNXB/C84rvc/ola8FMLUBF4roNNt4062EjXlUcKIHCCy/Xw4gkQzYG4pfr4MVsjUwp2D1SFFGGwx3Gp2/gZ1za7mGDoNHUeIZqGRxJmHlWatwaFcFh2yteyHRHh5L0WaJkMhoWrojXBf5S/Cl4BFr/5VuSFMuFV7JrEFkv9ybsiGEvsLT6c/bEhduqHSYj5wAvwHep7If92UO8accRP5AxAphkb6dlRc6kv+yJ+GABaNvxHMYJLwYai2/yvhpvvluT9BB/BtIct85Xh1BTcDpGnv1fhJo/dJPTcynjXY0i5GPVvQaOZbuyHdZEaCUJfSWAmERjYvpPlcamiTE=“;
};
zone “ru” {
type stub;
masters { 194.190.124.17; 193.232.156.17; 193.232.128.6; 193.232.142.17; 194.85.252.62; };
file “ru.stub”;
};
Similar is possible for all other nameservers.
> Incidentally, alternative DNS roots are nothing new. ICANN even has an
> info page on them:
>
> https://icannwiki.org/Alternative_Roots
>
> Nick
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx