So you are not looking at redirection as such (as that happens at the app level, i.e. on Apache/Nginx/wherever) but rather on the DNS resolution. The host on which DomainA is hosted will or should never be hit, based on your description as you want the DNS requests to be resolved to the IPs of DomainB. Unless I'm missing something in your request?
As Shane pointed out DNS is not capable of HTTP redirection - that's an application/webserver duty. You could make DomainA and DomainB resolve to the same IP on DNS and all would work. But if you're looking to do this on per URL/per-path way then this is not possible - DNS is not capable of that - it's a simple DNS->IP service, what's happening with the actual URL is the webserver's task.
After the comment below, what I'd do is to refer all DNS records for DomainA to the same IP(s) as DomainB is pointed to - this way you will get HTTP request hitting hostB and then it's just a simple matter of:
- creating a particular Apache Name Baseed Virtual host - which will be serving files from its own DocumentRoot
- creating permanent redirect on Apache like this:
This will rewrite anything coming to DomainB to DomainA which can be hosted on the same server or somewhere else. I appreciate that the second option is probably an overhead and not necessary if you can/are allowed to create Name Based Virtual hosts on apache.
<VirtualHost *:80>
ServerName DomainB
Redirect permanent / http://DomainA/
</VirtualHost>
I'd go with 1. - point all DNS records of DomainA to the same IP(s) as DomainB is pointing and create particular Name Based VirtualHosts on Apache.
Subordinate identification
Apex level NS records are used by a master server to identify its subordinates. When data on an authoritative nameserver changes, it will advertise this via DNS NOTIFY messages (RFC 1996) to all of its peers on that list. Those servers will in turn call back with a request for the SOA record (which contains the serial number), and make a decision on whether to pull down a more recent copy of that zone.
- It's possible to send these messages to servers not listed in the
NS section, but this requires server specific configuration directives (such as ISC BIND's also-notify directive). The apex NS records comprise the basic list of servers to notify under a default configuration.
- It's worth noting that the secondary servers will also send NOTIFY messages to each other based on these
NS records, usually resulting in logged refusals. This can be disabled by instructing servers to only send notifies for zones they are masters for (BIND: notify master;), or to skip NS based notifies entirely in favor of notifies explicitly defined in the configuration. (BIND: notify explicit;)
Authoritative definition
The question above contained a fallacy:
They are not used by caching DNS servers in order to determine the authoritative servers for the domain. This is handled by nameserver glue, which is defined at the registrar level. The registrar never uses this information to generate the glue records.
This is an easy conclusion to arrive at, but not accurate. The NS records and glue record data (such as that defined within your registrar account) are not authoritative. It stands to reason that they cannot be considered "more authoritative" than the data residing on the servers that authority is being delegated to. This is emphasized by the fact that referrals do not have the aa (Authoritative Answer) flag set.
To illustrate:
$ dig @a.gtld-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14021
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 172800 IN A 199.43.135.53
a.iana-servers.net. 172800 IN AAAA 2001:500:8f::53
b.iana-servers.net. 172800 IN A 199.43.133.53
b.iana-servers.net. 172800 IN AAAA 2001:500:8d::53
Note the lack of aa in the flags for the above reply. The referral itself is not authoritative. On the other hand, the data on the server being referred to is authoritative.
$ dig @a.iana-servers.net +norecurse +nocmd example.com. NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2349
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com. IN NS
;; ANSWER SECTION:
example.com. 86400 IN NS a.iana-servers.net.
example.com. 86400 IN NS b.iana-servers.net.
That said, this relationship can get very confusing as it is not possible to learn about the authoritative versions of these NS records without the non-authoritative NS records defined on the parent side of the referral. What happens if they disagree?
- The short answer is "inconsistent behavior".
- The long answer is that nameservers will initially stub everything off of the referral (and glue) on an empty cache, but those
NS, A, and AAAA records may eventually be replaced when they are refreshed. The refreshes occur as the TTLs on those temporary records expire, or when someone explicitly requests the answer for those records.
A and AAAA records for out of zone data (i.e. the com nameservers defining glue for data outside of the com zone, like example.net) will definitely end up being refreshed, as it is a well-understood concept that a nameserver should not be considered an authoritative source of such information. (RFC 2181)- When values of the
NS records differ between the parent and child sides of the referral (such as the nameservers entered into the registrar control panel differing from the NS records that live on those same servers), the behaviors experienced will be inconsistent, up to and including child NS records being ignored completely. This is because the behavior is not well defined by the standards, and the implementation varies between different recursive server implementations. In other words, consistent behavior across the internet can only be expected if the nameserver definitions for a domain are consistent between the parent and child sides of a referral.
The long and short of it is that recursive DNS servers throughout the internet will bounce back between destinations if the records defined on the parent side of the referral do not agree with the authoritative versions of those records. Initially the data present in the referral will be preferred, only to be replaced by the authoritative definitions. Since caches are constantly being rebuilt from scratch across the internet, it is impossible for the internet to settle on a single version of reality with this configuration. If the authoritative records are doing something illegal per the standards, such as pointing NS records at aliases defined by a CNAME, this gets even more difficult to troubleshoot; the domain will alternate between working and broken for software that rejects the violation. (i.e. ISC BIND / named)
RFC 2181 ยง5.4.1 provides a ranking table for the trustworthiness of this data, and makes it explicit that cache data associated with referrals and glue cannot be returned as the answer to an explicit request for the records they refer to.
5.4.1. Ranking data
When considering whether to accept an RRSet in a reply, or retain an
RRSet already in its cache instead, a server should consider the
relative likely trustworthiness of the various data. An
authoritative answer from a reply should replace cached data that had
been obtained from additional information in an earlier reply.
However additional information from a reply will be ignored if the
cache contains data from an authoritative answer or a zone file.
The accuracy of data available is assumed from its source.
Trustworthiness shall be, in order from most to least:
+ Data from a primary zone file, other than glue data,
+ Data from a zone transfer, other than glue,
+ The authoritative data included in the answer section of an
authoritative reply.
+ Data from the authority section of an authoritative answer,
+ Glue from a primary zone, or glue from a zone transfer,
+ Data from the answer section of a non-authoritative answer, and
non-authoritative data from the answer section of authoritative
answers,
+ Additional information from an authoritative answer,
Data from the authority section of a non-authoritative answer,
Additional information from non-authoritative answers.
<snip>
Unauthenticated RRs received and cached from the least trustworthy of
those groupings, that is data from the additional data section, and
data from the authority section of a non-authoritative answer, should
not be cached in such a way that they would ever be returned as
answers to a received query. They may be returned as additional
information where appropriate. Ignoring this would allow the
trustworthiness of relatively untrustworthy data to be increased
without cause or excuse.
Best Answer
Have a look at DeNIC's Nameserver Predelegation Check.
Short version: your DNS servers for
waverocker.orgdon't actually allow queryingwaverocker.de.