[dns-operations] Weirdness with glue for old (gone) DNS servers

[Patrik Fältström]

One have to remember that if example.com have an ns in ns.example.net and example.net is not renewed, there are already problems between example.com and example.net that can not really be resolved by adding technical/engineering algorithms on it.

Hey, people even get it wrong when glue is needed. People will continue to hurt themselves given sharp enough tools.

I think in the example you list Andrew, where you have example.com with NS ns.example.com and then example2.com with NS ns.example.com, first of all ns.example.com is not needed as an object for example2.com as the name is not in the delegated zone. I.e. we should use same rules as for glue.

But sure, in some cases you might have cross references that makes glue be needed, and in that case I think ns.example.com should be removed when example.com is removed. Reason for this is that I do see larger problems if ns.example.com exists and someone else is then registering example.com and "inherits" the ns.example.com object.

I.e. just like we have lame delegations (or the inverse, zones with NS which A or AAAA does not resolve) we should accept that in the SRS as well.

I do not see any way out of it.

   Patrik

On 15 maj 2014, at 06:07, Andrew Sullivan <ajs at anvilwalrusden.com> wrote:

> On Wed, May 14, 2014 at 03:07:01PM -0700, Dave Warren wrote:
>> I *think* the concern is that the registry might be reluctant to
>> modify the configuration for one zone due to a change made on
>> another, administratively unrelated, zone.
> 
> No, the registry doesn't modify anyone's zone configuration.  Just the
> registry's zone.  
> 
> The problem is that the registry has delegated to the registrar the
> authority over a name space.  Within that name space, the registrar
> changes the name of an object.  This is entirely within their rights,
> because they own the object _by virtue of_ the delegation of the name
> space.  This has side effects for some other name in the registry, and
> the answer to that is, "Too bad.  You shouldn't have used a nameserver
> in your NS record if they weren't going to tell you they were changing
> its name.  And if they _did_ tell you, why didn't you update it?"
> 
> Let me see if I can make it clearer.  Suppose we have two timelines:
> 
> RegistrarA
> ----1------2-----4----5---6--->
> 
> -------------3------------7--->
> RegistrarB
> 
> 
> 1.  RegistrarA registers example.com.
> 
> 2.  Registrant of example.com stands up a name server there, and sends
> glue records through RegistrarA for ns.example.com.  
> 
> 3.  RegistrarB creates example2.com with a nameserver ns.example.com.
> 
> 4.  Registrant of example.com doesn't pay the bill.  RegistrarA
> doesn't want to pay for the renewal of example.com.  It tries to
> delete the name, but can't because of an existing subordinate host
> (see RFC 5731 section 1.1).
> 
> 5.  RegstrarA tries to delete ns.example.com, but this is denied
> because of the link to domain object example2.com (see RFC 5732
> section 3.2.2).
> 
> 6.  RegistrarA renames ns.example.com to
> ns.example.com.lamedelegations.registrara.com.  By putting the
> "lamedelegations" label in there, they are using the only real
> signalling mechanism they have in the registry to point out the
> problem.  RegistrarA can now delete example.com and not have to pay
> the registration fee for the year.
> 
> 7.  The registry generates zone changes for the registry's zone, and
> the NS for example2.com becomes
> ns.example.com.lamedelegations.registrara.com., thereby making
> example2.com lame.  It still works because of the glue records that
> continue to be carried with the host name.
> 
> I think it would be nice to use the Shared Registration System (that's
> what "SRS" stands for) to facilitate this communication, but as it
> happens everyone disagreed with that idea in 2003 or so.
> 
>> How about when a domain under .com disappears, how would .org know
>> to change/remove the delegation.
> 
> This happens all the time, actually.  The nice thing in that case,
> however, is because those are "external" names, there's no glue, so
> the delegation starts failing as soon as caches time out.  For some
> value of "nice".
> 
> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> ajs at anvilwalrusden.com
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20140515/c46acb43/attachment.sig>