> On 4 May 2018, at 8:36 am, Bill Woodcock <wo...@pch.net> wrote: > > > >> On May 3, 2018, at 3:27 PM, David Huberman <david.huber...@icann.org> wrote: >> In practical terms, when any type of registry strips away a lame delegation >> attached to a real, operating network with users behind it, and things break >> as a result… > > But isn’t that, by definition, impossible? What could break as a result of a > _lame_ delegation being removed? > > They’d have to be spoofing a real IP address behind their firewall, which > isn’t supposed to work anyway. > > -Bill
A “Lame Delegation” can be to a particular machines. These delegation for .fj are lame and have been for over a year. fj. @128.32.136.3 (adns1.berkeley.edu.): dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused optlist=refused signed=refused ednstcp=refused fj. @2607:f140:ffff:fffe::3 (adns1.berkeley.edu.): dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused optlist=refused signed=refused ednstcp=refused fj. @128.32.136.14 (adns2.berkeley.edu.): dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused optlist=refused signed=refused ednstcp=refused fj. @2607:f140:ffff:fffe::e (adns2.berkeley.edu.): dns=refused edns=refused edns1=ok edns@512=refused ednsopt=refused edns1opt=ok do=refused ednsflags=refused optlist=refused signed=refused ednstcp=refused But because .fj has multiple servers fj. 86400 IN NS ns1.berkeley.edu. fj. 86400 IN NS teri.usp.ac.fj. fj. 86400 IN NS ns2.berkeley.edu. fj. 86400 IN NS rip.psg.com. fj. 86400 IN NS manu.usp.ac.fj. fj. 86400 IN NS auth00.ns.uu.net. the service is still up. In the meantime .fj doesn’t have the level of redundancy they presumably think they have and every resolver in the world spends time discovering that they are broken. There are others like these where the servers fail to respond to certain classes of legitimate DNS queries. westlaw.com.au. @146.242.20.65 (ns-emea-1.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok westlaw.com.au. @146.242.18.65 (ns-amers-1.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok westlaw.com.au. @146.242.19.65 (ns-amers-2.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok westlaw.com.au. @146.242.21.65 (ns-emea-2.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok westlaw.com.au. @146.242.22.65 (ns-apac-1.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok westlaw.com.au. @146.242.24.65 (ns-apac-2.thomsonreuters.net.): dns=ok edns=noopt edns1=timeout edns@512=noopt ednsopt=timeout edns1opt=timeout do=ok ednsflags=noopt optlist=timeoutsigned=ok ednstcp=ok Why should resolvers have to work around idiocy like this? Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
