Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Author Topic: To offer recursion to slave.dns.he.net or NOT?  (Read 767 times)

illusive7

  • Newbie
  • *
  • Posts: 2
To offer recursion to slave.dns.he.net or NOT?
« on: February 05, 2022, 07:41:14 AM »

In the ISC Bind9.11 named log, I get the following message:

```
debug 3:  216.218.133.2#13482: view red: request has valid signature: public-master-to-public-secondary
debug 3:  216.218.133.2#13482/key public-master-to-public-secondary: view red: recursion not available
debug 3:  216.218.133.2#13482/key public-master-to-public-secondary (MYDOMAIN.NET): view red: query 'mydomain.net/SOA/IN' approved
debug 3:  216.218.133.2#13482/key public-master-to-public-secondary (MYDOMAIN.NET): view red: reset client
```
Note: 216.218.133.2 is the out-of-band secdonary `slave.dns.he.net` DNS server that is performing the AXFR (pull) from my authoritative master DNS server (whose IP shall be left out for MYDOMAIN.NET)

Please notice the `recursion not available`.

Question is:

1.  Why is `slave.dns.he.net` performing a recursive querying?

2. And should we, the customers, be actually offering 'recursion' to this `slave.dns.he.net`?

3  Or is this a simple ISP test of ensuring that our customers' DNS server is NOT being "recursive" (having recursion enabled)?

```
Logged

snarked

  • Hero Member
  • *****
  • Posts: 810
Re: To offer recursion to slave.dns.he.net or NOT?
« Reply #1 on: February 05, 2022, 10:12:16 AM »

Recursion is not needed for zone transfers.  However, it could be set on the query that checks the SOA serial field, but certainly any extra data is not used.  Having it set may be just an oversight.
Logged

illusive7

  • Newbie
  • *
  • Posts: 2
Re: To offer recursion to slave.dns.he.net or NOT?
« Reply #2 on: February 05, 2022, 11:32:43 AM »

Hey @snarked,

Ohhhhtay.  Looks like Hurricane Electric secondary updater (be that it may, the slave.dns.he.net or the ns1.he.net) is actually performing a full recursive querying on this customer's MYDOMAIN.NET hostname based, then taking the customer's (source) IP address and TSIG keyname to consult the "secondary HE customer" lookup database, as part of HE system design of "receive NOTIFY on one end, and AFXR on other end network process.

Perhaps, this HE secondary design of a simply querying of the customer's domain name could be refined then its DNS messaging exchange be broken up by actively going to each zone NS server (do a non-recursive query) and then heading to the next zone NS server (ad naseum) thereby avoiding any semblance of a recursion.

Unless there is another aspect to this split-highway update process and its usage of recursive querying that I am not aware of.  But hey, what do I know.  Just thinking outloud here.
« Last Edit: February 05, 2022, 11:38:04 AM by illusive7 »
Logged