Should DNS servers communicate with IPv6 only DNS server

NSD
1

Hello,

I'm using NSD DNS server and this year I have to make my DNS servers to be
available only by IPv6. I tested with several well-known public DNS servers
and they give expected results for one of my host: isu.bkoty.ru but some
(most?) public DNS servers don't return answer but SERVFAIL (as host tells
me).

For example:

---------------------------------- 8< --------------------------------------

$ host isu.bkoty.ru 77.88.8.8
Using domain server:
Name: 77.88.8.8
Address: 77.88.8.8#53
Aliases:

Host isu.bkoty.ru not found: 2(SERVFAIL)

---------------------------------- 8< --------------------------------------

$ dig isu.bkoty.ru @77.88.8.8

; <<>> DiG 9.16.8 <<>> isu.bkoty.ru @77.88.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58863
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;isu.bkoty.ru. IN A

;; Query time: 89 msec
;; SERVER: 77.88.8.8#53(77.88.8.8)
;; WHEN: Пт дек 04 10:48:56 +08 2020
;; MSG SIZE rcvd: 41

---------------------------------- 8< --------------------------------------

While cloudflare DNS reports the address:

---------------------------------- 8< --------------------------------------

$ host isu.bkoty.ru 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:

isu.bkoty.ru has address 185.185.68.15
isu.bkoty.ru has IPv6 address 2a0a:2b40::4:143
isu.bkoty.ru mail is handled by 10 mail.bkoty.ru.

---------------------------------- 8< --------------------------------------

$ dig isu.bkoty.ru @1.1.1.1

; <<>> DiG 9.16.8 <<>> isu.bkoty.ru @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21767
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;isu.bkoty.ru. IN A

;; ANSWER SECTION:
isu.bkoty.ru. 600 IN A 185.185.68.15

;; Query time: 79 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Пт дек 04 10:49:53 +08 2020
;; MSG SIZE rcvd: 57

---------------------------------- 8< --------------------------------------

I know this is not NSD specific question but could someone on the list give me
a hint or link to some document(s) (may be RFC) that describes common practice
about server communitations? How should DNS server communitate with other
(authoritative) DNS server: by using only IPv4 or use both IPv4 and IPv6
addresses? Should I report to DNS providers that they DNS server (resolver?)
doesn't contact authoritative DNS server by IPv6 or simply avoid to use such
DNS providers?

2

I know this is not NSD specific question but could someone on the list give me
a hint or link to some document(s) (may be RFC) that describes common practice
about server communitations? How should DNS server communitate with other
(authoritative) DNS server: by using only IPv4 or use both IPv4 and IPv6
addresses? Should I report to DNS providers that they DNS server (resolver?)
doesn't contact authoritative DNS server by IPv6 or simply avoid to use such
DNS providers?

  ( I think a v6-only server, today, is of limited albeit growing
  usefulness, in and of itself. As a member in the NS RRSET for
  a domain, where the aggregate is dual-stack, yes, then it is a
  good addition.)

As to resolver behaviour, I would argue that dual-stack is very desirable
in a resolver, more so than in a namne server, which of course depends on
it being a SPOF for the client until timeout kicks in. And consequently,
I think that a full-service resolver should use all available means to
reach its data sources.

Regarding "reporting", well, you could ask them why they've not dual-stacked
their outgoing queries, and point to RFC 6540.

Related to that, I strongly argue that "resolver providers" are a less
than optimal centralisation of something that is best done at the network
edge. I would encourage every so capable entity to operate their own
validating resolver, as close to the clients as feasible, and do away
with the dependency on a datamining bigco.

Regards,