Re: Reporter re: Technical solution for robust interconnection if Russia & BRICs set own root?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stephane Bortzmeyer wrote:
> On Wed, Jan 03, 2018 at 11:54:42PM +0000, Nick Hilliard <nick@xxxxxxxxxx> wrote 
>> > 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.
> 
> I don't see the relationship with the structure of the domain name
> tree, or with the role of the root.

early versions of bind were notoriously prone to cache poisoning from
arbitrary replies to dns requests.  When some of the early alternate
roots appeared on the scene (AlterNIC and eDNS come to mind), DNS
servers from root X would reply authoritatively to requests from DNS
resolvers, and the resolvers would reply to clients with both records
and glue from the alternative roots.  There were other bugs where you
could include authoritative responses to domains that the resolvers were
authoritative for, and this information would be served as authoritative.

[As a side note, the auth+resolver on the same box problem happened
because it wasn't possible to configure multiple IP addresses on the
same interface for many years on any of the standard operating systems
(sunos3/sunos4, freebsd1/2, linux 0.9*), and there was no such thing as
virtualisation, which meant that if you wanted 2 auth servers and 2
resolvers, that meant 4 physical boxes, and they cost a fortune at the
time.]

>From our perspective in 2017, this was cripplingly broken behaviour, but
nevertheless it was the state of affairs in the mid 1990s and a bunch of
the cache poisoning fixes were implemented partly because the
alternative roots created cross-contamination problems.

> icannwiki.org is NOT managed by ICANN.

didn't realise - thanks for the correction. The point I was making was
that alternative roots have been on the scene for a long time.

Nick




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]