A lame delegation occurs when a nameserver (NS) record for a domain or subdomain specifies an authoritative nameserver that is incorrect or improperly configured and cannot serve DNS data for the domain. For example, if the NS record at the top-level domain (TLD) or parent zone points to NS1 nameservers, but the corresponding DNS zone is not published to those NS1 nameservers, this is considered a lame delegation. In addition to prolonging the DNS resolution process, lame delegations present a security risk and must be corrected as soon as possible.
Lame delegation hijacking refers to a situation in which a person or entity takes advantage of expired or incorrect nameserver domains to manipulate DNS resolution. Hijacked domains are often used to redirect incoming DNS traffic to fraudulent or malicious content while still appearing as though the domains are owned and operated by the domain registrants.
The IBM NS1 Connect platform has controls in place to help prevent lame delegation hijacking and enhance zone ownership security. NS1 puts a hold on zones that are delegated to NS1 authoritative nameservers, but the zone does not yet exist on the platform. Doing this prevents malicious actors from hijacking the zone if the delegation was updated before the zone was created.
We recommend the following best practices to help avoid lame delegation hijacking:
Do not update the nameserver delegation until you have created the DNS zone on the IBM NS1 Connect platform and are ready to initiate traffic flow through NS1 authoritative nameservers. In addition to reducing the risk of lame delegation, creating the zone first helps avoid a zone collision if the zone is on hold by the NS1 Connect platform pending owner verification.
Note: If you experience issues creating a zone due to a zone collision, contact the customer support team to verify that you are the owner of the domain and to resolve the issue.
Maintain a healthy DNS lifecycle management process by checking your nameserver delegations at the domain registrar, primary zone, or parent zone.
Configure DNSSEC on your primary zones and subdelegations to apply cryptographic authentication, allowing recursive DNS resolvers to validate responses from the authoritative nameservers.