Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm looking to set up BIND to return the same IP address for every A record, no matter what the request is. It's working based on the configuration below, however what is not working is that the ns records are not being returned correctly, as is required by some domain registrars.

/etc/named.conf:

zone "." IN {
    type master;
    file "named.root";
};

/var/named/named.root:

$ORIGIN .
$TTL 1H
@       IN      SOA     . hostmaster.uafrica.net. ( 20121020 1D 1H 1W 3H );
@       IN      NS      ns1.uafrica.net.
@       IN      NS      ns2.uafrica.net.
*.      IN      A       46.38.178.141
ns1.uafrica.net.        IN      A       184.106.174.139
ns2.uafrica.net.        IN      A       31.222.155.45

Querying the nameserver directly using dig:

$ dig @ns1.uafrica.net ubookings.co.za
; <<>> DiG 9.7.3-P3 <<>> @ns1.uafrica.net ubookings.co.za
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46866
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;ubookings.co.za.       IN  A
;; ANSWER SECTION:
ubookings.co.za.    3600    IN  A   46.38.178.141
;; AUTHORITY SECTION:
.           3600    IN  NS  ns1.uafrica.net. // <b>*The domain is not being returned (only a period)</b>
.           3600    IN  NS  ns2.uafrica.net.
;; ADDITIONAL SECTION:
ns1.uafrica.net.    3600    IN  A   184.106.174.139
ns2.uafrica.net.    3600    IN  A   31.222.155.45
;; Query time: 443 msec
;; SERVER: 184.106.174.139#53(184.106.174.139)
;; WHEN: Tue Oct 30 14:41:17 2012
;; MSG SIZE  rcvd: 126

It seems the problem might be that only a period is being returned under the AUTHORITY SECTION above (instead of the domain name). Also, doing a dig for the nameserver records does not return the ns records as expected:

dig @ns1.uafrica.net ubookings.co.za ns
; <<>> DiG 9.7.3-P3 <<>> @ns1.uafrica.net ubookings.co.za ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39694
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
ubookings.co.za.        IN  NS
;; AUTHORITY SECTION:
.           3600    IN  SOA . hostmaster.uafrica.net. 20121020 86400 3600 604800 10800
;; Query time: 716 msec
;; SERVER: 184.106.174.139#53(184.106.174.139)
;; WHEN: Tue Oct 30 14:43:34 2012
;; MSG SIZE  rcvd: 89

Any ideas on how to get bind to return the ns records as part of this wildcard configuration would be very much appreciated (if I create a zone with a specific domain the ns records get returned correctly but I need this to work as a wildcard without having to create specific zones for each domain).

share|improve this question

closed as unclear what you're asking by Chris S Apr 28 at 3:25

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Everything you describe sounds normal. The zone you are serving is "." so of course the nameservers in the authority and/or additional section are going to be for that zone. What else would you have them be? Is the current configuration causing any problems? –  Celada Oct 30 '12 at 15:19
    
Thanks for the response. Yes, this configuration is causing a problem in that when trying to register a domain with a .co.za cTLD, the registrar gives an error saying that no ns records exist for the domain. I think the registrar needs to get a specific answer to the query dig @ns1.uafrica.net ubookings.co.za ns which is not happening with this configuration. –  Andy Higgins Oct 30 '12 at 15:27
3  
Why are you trying to make it answer for every domain instead of just having a wildcard record within ubookings.co.za? –  mgorven Oct 31 '12 at 0:28
    
We need it to answer for every domain because at the time a domain is registered we do not know what the domain is going to be and we do not want to have to add entries beforehand (and have wait for propagation to happen). –  Andy Higgins Oct 31 '12 at 8:16
1  
@AndyHiggins I guess it's the way /everyone/ does it. And for authoritative DNS you do not need any propagation, the registrars contact the authoritative nameservers directly. If you're using AXFR, abandon it (if you are controlling both nameservers) and configure both ns1 and ns2 in parallel. –  Michuelnik Oct 31 '12 at 9:15

3 Answers 3

What about just adding the required NS RRs?

Say your want to register ubookings.co.za, your registrar needs corresponding IN NS records like this in your zone above:

ubookings.co.za     IN  NS   ns1.uafrica.net.
ubookings.co.za     IN  NS   ns2.uafrica.net.

It might be possible that your zone also needs a matching IN SOA also for your domain.

share|improve this answer
    
Yes. That would work but only for that specific domain. We need it to work as a wildcard for any domain without having to specify each domain individually. –  Andy Higgins Oct 31 '12 at 8:18
    
might that work with a wildcard also? * IN NS ns1....? –  Michuelnik Oct 31 '12 at 9:12
    
I tried various options including the wildcard for the NS records e.g. * IN NS ns1.uafrica.com or *. IN NS ns1.uafrica.com or @ IN NS ns1.uafrica.com or IN NS ns1.uafrica.com but they do not work. With the wildcard when restarting the named service it gives the following error "invalid NS owner name (wildcard)" –  Andy Higgins Oct 31 '12 at 10:17
    
Then it looks like it's not going to work - with bind. Perhaps unbound (although being a caching resolver) with the python-module. There you can respond to every IN NS query with very little scripting. –  Michuelnik Oct 31 '12 at 14:53
*.*     IN  NS   ns1.uafrica.net.
*.*.*   IN  NS   ns2.uafrica.net.

(But I still convinced that you are trying to achieve something absolutely wrong)

share|improve this answer

What you are doing in that BIND configuration is fundamentally unsound.

When a zone is delegated to your nameservers the expectation is that you have that specific zone. (This is not something that a specific registrar requires, whether or not some choose to validate this, it's a fundamental requirement in the protocol.)

At the apex of any zone there are at least SOA + NS records and if your nameserver denies the existance of those NS records then you are really begging for trouble (if someone asks your nameservers, they will know for a fact that there are no nameservers).

Also, as you mention in the question your nameserver will refer back to the SOA at the zone apex in responses where the requested data was not found. In this situation you are saying that you are the authority for the root zone which is clearly misinformation.

As for adding NS records somewhere below the zone apex, that does not actually add data in your zone but rather define that your zone has ended at that point. These NS records are not used as answers, only to provide authority information.

You'll find that no normal nameserver software that has a defined set of zones will work properly for what you are trying to do.

I'd imagine it's possible (at least for a non-DNSSEC scenario) to have a nameserver that when queried for foo.example.com takes the last labels (ie example.com) and behaves as if it had a zone with some predefined data. I do not know of any such software, however, and it seems like a rather niche thing so whether you find something that does this or decide to implement something custom for your needs I believe you will have to do extensive testing to ensure it actually functions properly (ie, it actually provides answers that are consistent).

share|improve this answer

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