Re: [DNSOP] on what glue is (was: signing glue and additional data)

Roy Arends <> Mon, 18 January 2010 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 467153A68E9 for <>; Mon, 18 Jan 2010 08:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.853
X-Spam-Status: No, score=-0.853 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_QP_LONG_LINE=1.396]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nSS7LKuflrLC for <>; Mon, 18 Jan 2010 08:01:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0FD103A6886 for <>; Mon, 18 Jan 2010 08:01:20 -0800 (PST)
Received: from [] (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: roy) by (Postfix) with ESMTPSA id A0D3F2D590; Mon, 18 Jan 2010 17:01:12 +0100 (MET)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="utf-8"
From: Roy Arends <>
In-Reply-To: <>
Date: Mon, 18 Jan 2010 11:01:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <C70EBA7D41694531819FB0923455C684@localhost> <C7567F001CD94F1891C91E162FD5316B@localhost> <> <5F83DF543FF0440E8D295E5C5B11C9D6@localhost> <>
To: Andrew Sullivan <>
X-Mailer: Apple Mail (2.1077)
Subject: Re: [DNSOP] on what glue is (was: signing glue and additional data)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Jan 2010 16:01:21 -0000

On Jan 18, 2010, at 9:46 AM, Andrew Sullivan wrote:

> On Sat, Jan 16, 2010 at 02:54:52PM -0000, George Barwood wrote:
>> Ok, you can argue over the definition of what a glue record is.
> Indeed, there was an I-D floating about that offered to do exactly
> that.  It's expired, though:
> Perhaps someone should take that up?

I've wrote an article about this about 4 years ago, here's the yeast of it:


The concept of glue records (address records such as A and AAAA) exists _solely_ in zones and are related to delegations. The term is not used to refer to address records that appear in DNS requests and responses. Glue records are useful to a resolver so it can locate the delegated nameserver. I'll try to explain the terminology involved and the process of determining which records are called glue. Glue addresses are related to delegation point NS records. 

We need three properties of a delegation point NS record to determine if an associated address is glue:

  APEX: the name of the zone that contains the delegation point NS record.
  NSOWNER: the ownername (left hand side) of the delegation NS record.
  NSDNAME: the NSDNAME (right hand side) of the delegation NS record.

All these properties are fully qualified domain names.

We can describes 4 classes of NSDNAME:

  1) offtree: NSDNAME is not a subdomain of, nor equal to the APEX.
  2) authoritative: NSDNAME is a subdomain of APEX, and, NSDNAME is not equal to nor a subdomain of any NSOWNER.
  3) in-bailiwick: NSDNAME is a subdomain of APEX, and, NSDNAME is equal to or a subdomain of NSOWNER.
  4) sibling: NSDNAME is a subdomain of APEX, and, NSDNAME is equal to or a subdomain of some other NSOWNER.

An NSDNAME is the hostname of the nameserver. Nameservers’ addresses are stored in A or AAAA records. If NSDNAME is of class 1 or 2, the corresponding addresses are NOT glue. 
In class 1, the addresses are not even in the zonefile. 
In class 2, the addresses are in the zone, and are authoritative data. Note that for the root zone, class 1 simply does not exist, since the entire dns tree are subdomains of root.

If NSDNAME is in class 3 or 4, the corresponding addresses are glue addresses.


In class 3 (’in-bailiwick’) it is required to have that address in the zone. As an example, assume the following NS record:

  alpha.tld. NS ns1.alpha.tld.

The alpha.tld zone resides on nameserver ns1.alpha.tld. A resolver can’t reach alpha.tld without the address of ns1.alpha.tld. To resolve ns1.alpha.tld, it needs to reach alpha.tld. To route around this chicken and egg problem, the tld zone needs to have an address for ns1.alpha.tld. So, class 3 ‘in-bailiwick’ requires glue. We call this glue ‘in-bailiwick glue’.

In class 4 (’sibling’), it is not required to have that address in the zone, unless there are circular dependencies. As an example of a circular dependency, assume the following NS records:

  foo.tld. NS
  bar.tld. NS

The ‘foo’ and ‘bar’ delegation have a circular dependency. Foo resides on a server under bar, bar resides on a server under foo. A resolver can’t reach foo without the address for which is in the bar zone, and it can’t reach bar without the address of which is in the foo zone. Hence the ‘tld’ zone needs, in this specific case, address records for both and Note that circular depenency graphs can be complex, and paths in the graph can be long. A resolver will more than likely have measures against looping and long path lengths.

Orphan Glue Phenomenon

An interesting phenomenon occurs when a delegation NS record set is removed from the zone while the glue records that reside under it, are not removed. These glue records are now class 2 (authoritative) records. We call these addresses 'orphan glue' records, though they are not glue anymore (they've been adopted) 

DNSSEC and Glue

Glue addresses are not signed. They are supposed to be signed in the zone that is authoritative for the address record. They also do not appear in NSEC or NSEC3 chains. However, when glue addresses become orphan (see 'orphan glue phenomenon') they are now authoritative data, and subsequently need to be signed. 

Wide and narrow glue policy. 

These policies determine what types of glue (class 3 or class 4) are allowed in a zone.

Wide glue policy allows both class 3 (in-bailiwick glue) and class 4 (sibling glue) to be registered in the zone. Narrow glue policy allows class 3 only. A combination of the two policies ‘case-by-case policy’ exists where sibling glue is only registered to avoid circular dependencies.

The dependency problem exists not only with missing glue. It can be that foo.tld resides on a nameserver ‘ns1.cow.moo’ and ‘cow.moo’ resides on a nameserver ‘’. Both the moo and tld registries are not allowed (by dns-protocol) to serve off-tree addresses. So, while gluelessness can be avoided for class 4, it can not be avoided for class 1.

Kind regards,

Roy Arends
Sr Researcher
Nominet UK