I have to delegate test.example.com to third party provider. Using BIND, in the example.com zone file I set up six NS records like this:

test            IN      NS      a.ns.test.example.com.
test            IN      NS      b.ns.test.example.com.
test            IN      NS      c.ns.test.example.com.
test            IN      NS      d.ns.test.example.com.
test            IN      NS      e.ns.test.example.com.
test            IN      NS      f.ns.test.example.com.

They specifically ask for delegating like this. I then set up the glue records:

a.ns.test       IN      A       IP1
a.ns.test       IN      A       IP2
a.ns.test       IN      A       IP3
a.ns.test       IN      A       IP4
a.ns.test       IN      A       IP5
a.ns.test       IN      A       IP6

Now if I query for the A record of a.ns.test.example.com. with dig I get a response with an AUTHORITY SECTION and ADDITIONAL SECTION, but no ANSWER SECTION. I assume this is by design, to avoid lame delegation problems, so that a resolver caches results from the authoritative servers. However, the third party will NOT turn on the service we want from them unless our servers return an A record.

How can I do that with BIND?


Records returned as glue are never authoritative and will never appear in the answer section. If the provider just wants to verify that the glue exists, they should see it in the additional section.

Whoever is running the a-f.ns.test.example.com nameservers will need to add the A or AAAA records in the test.example.com zone since your delegating nameserver cannot.

BIND will automatically turn A records into glue when they are providing addresses for nameservers for zones you are delegating away. Once you set up a delegation as you have with test.example.com, BIND will treat any A or AAAA records for hosts you're delegating to as glue only.

Here is a dig with the delegation removed:

; <<>> DiG 9.7.0-P1 <<>> +norecurse @0 a.ns.test.example.com a
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;a.ns.test.example.com.     IN  A

a.ns.test.example.com.  5   IN  A

example.com.        5   IN  NS  gir.example.com.

ns.example.com. 5   IN  A

;; Query time: 0 msec

It is answering authoritatively. Here is the same with only the delegation added (the first block in your question):

; <<>> DiG 9.7.0-P1 <<>> +norecurse @0 a.ns.test.example.com a
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6

;a.ns.test.example.com.     IN  A

test.example.com.   5   IN  NS  f.ns.test.example.com.
test.example.com.   5   IN  NS  d.ns.test.example.com.
test.example.com.   5   IN  NS  a.ns.test.example.com.
test.example.com.   5   IN  NS  c.ns.test.example.com.
test.example.com.   5   IN  NS  e.ns.test.example.com.
test.example.com.   5   IN  NS  b.ns.test.example.com.

a.ns.test.example.com.  5   IN  A
b.ns.test.example.com.  5   IN  A
c.ns.test.example.com.  5   IN  A
d.ns.test.example.com.  5   IN  A
e.ns.test.example.com.  5   IN  A
f.ns.test.example.com.  5   IN  A

;; Query time: 0 msec

Notice the A records for a-f.ns.test are now glue. This is done automatically. Since you are delegating test.example.com, the superordinate nameservers can no longer answer authoritatively for anything in test.example.com. They can, however, return the A records in the zone as glue since they are delegating to them.

  • This is my understanding as well. However, the people managing test.example.com have a script to test delegation before setting up the zone file. As far as I can tell, this script tests for the A records with host, which does not return any since, the delegated zone is still not set up. So basically my question is if there is some hack to tell BIND te reply with an A record, even if it is not authoritative, or, worse yet, set the authoritative bit. I know I shouldn't do this, but anyone dealing with clueless external service providers will understand my frustration. – Prof. Moriarty Apr 12 '11 at 9:30
  • They should know that the authoritative records for test.example.com belong in test.example.com, not your zone. You can make it respond authoritatively by removing the delegation, but they might be checking for that, too. Better, they should fix their script to look for glue in the additional section where it belongs. :) – Cakemox Apr 12 '11 at 9:34
  • +1; sounds like their script is at fault. – nickgrim Apr 12 '11 at 11:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.