1

There is a KNOT DNS master name server that I do not manage myself for my domain. I try to setup a BIND DNS server as a slave in-house. BIND fails to do the zone transfer and reports

31-Dec-2017 16:19:02.503 zone whka.de/IN: Transfer started.
31-Dec-2017 16:19:02.504 transfer of 'whka.de/IN' from 2001:7c7:2000:53::#53: connected using 2001:7c7:20e8:18e::2#53509
31-Dec-2017 16:19:02.505 transfer of 'whka.de/IN' from 2001:7c7:2000:53::#53: failed while receiving responses: NOTAUTH
31-Dec-2017 16:19:02.505 transfer of 'whka.de/IN' from 2001:7c7:2000:53::#53: Transfer completed: 0 messages, 0 records, 0 bytes, 0.001 secs (0 bytes/sec)

If try dig (this time using the IPv4 address), I get a failure, too.

# dig axfr @141.70.45.160 whka.de.

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> axfr @141.70.45.160 whka.de.
; (1 server found)
;; global options: +cmd
; Transfer failed.

Wireshark tells me that the reply code of the name server is 1001 Server is not an authority for domain. What is going on here?

Especially, if I query the same nameserver for an usual A-record it claims to be authoritative. Moreover, KNOT DNS manual says KNOT is an authoritative-only name server. So there is no way of being non-authoritative.

Has anybody already observed something like this?

Here is my BIND configuration, but at the moment I doubt that BIND is the problemativ part of it:

// *The whole IP range of HEKnet*
//
// These are allowed to query our own nameserver; see `allow-query { heknet; };`
// below
acl heknet {
  127.0.0.0/8;
  100.122.0.0/18;
  100.67.128.16/29;
  ::1/128;
  2001:7c7:20e8::0/47;
  2001:7c7:200e:2::/64;
};

// *The IP address(es) of this nameserver itself*
//
// Required for control and notify messages
acl hek-ns {
  127.0.0.0/8;
  100.122.2.2;
  ::1/128;
  2001:7c7:20e8:18e::2;
};


// *The IPs of the authoritive nameserver of `whka.de`*
//
// These are allowed to send update-notifications to our nameserver; see
// `allow-notify { whka-ns; };` below
// `dns0.whka.de` is the hidden master of `dns1.whka.de` and `dns2.whka.de`.
// It must not be used for usual name queries, but only for zone updates.
// `dns1.whka.de` and `dns2.whka.de` are the ordinary servers for daily
// operation.
acl whka-ns {
  // dns0.whka.de., dns1.whka.de., dns2.whka.de.
  141.70.45.160;
  141.70.45.161;
  141.70.45.162;
  2001:7c7:2000:53::;
  2001:7c7:2000:53::1;
  2001:7c7:2000:53::2;
};


// *The master nameserver of `whka.de`*
//
// `dns0.whka.de` is the hidden master. This means it must only be used for
// zone transfers and not for ordinary name queries. It does not claim itself
// being a nameserver of `whka.de`.
masters whka-dns0 {
  141.70.45.160;
  2001:7c7:2000:53::;
};


options {
  directory "/var/cache/bind.new";

  listen-on port 1053 { any; };

  listen-on-v6 port 1053 {  any; };

  forwarders {
    // KIT name servers, the whka-nameservers do not allow recursion
    129.13.64.5;
    129.13.96.2;
  };

  forward first;
  notify no;

  allow-query { heknet; };

  allow-recursion { heknet; };

  allow-query-cache { heknet; };

  allow-notify {
    hek-ns;
    whka-ns;
  };
}; 

controls {
  inet * port 1953 allow { hek-ns; };
};


zone "whka.de." {
  type slave;
  masters { whka-dns0; };
  file "/var/lib/bind.new/db.de.whka";
};

zone "122.100.in-addr.arpa." {
  type slave;
  masters { whka-dns0; };
  file "/var/lib/bind.new/db.100.122";
};

zone "67.100.in-addr.arpa." {
  type slave;
  masters { whka-dns0; };
  file "/var/lib/bind.new/db.100.67";
};

zone "0.2.7.c.7.0.1.0.0.2.ip6.arpa." {
  type slave;
  masters { whka-dns0; };
  file "/var/lib/bind.new/db.2001.07c7.20";
};
1
  • 1
    The server at 141.70.45.160 is simply refusing to let you do a zone transfer (AXFR). Perfectly ordinary. Jan 1, 2018 at 15:52

1 Answer 1

1

NOTAUTH code is overloaded in the standards, unfortunately. In this case it means "not authorized". https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .