> On 4 Oct 2024, at 10:43, 大浦 義 wrote:
>
> Are searches from one authoritative zone to another authoritative zone using
> cname no longer allowed?
It is pointless to follow CNAMEs when returning non recursive (RA=0) responses
as recursive servers throw the rest of the response away to prevent
If you want it to chase down the CNAME target data from another zone,
you're asking for recursion, not authoritative-only, so those results make
perfect sense.
Think of it this way. The fact both zones happen to be served by the same
name server is irrelevant. You should get the same authoritative
Are searches from one authoritative zone to another authoritative zone using
cname no longer allowed?
/etc/named.conf
acl "local" {
xxx.xxx.xxx.xxx; 127.0.0.1;
};
・
・
・
allow-recursion { local; };
--
Client xxx.xxx.xxx.xxx→9.9.4:OK 9.9.18:OK
Client yyy.yyy.yyy.yyy(not include acl) →9.9.
Dear.
・9.9.4
Master
ns0.bbb.co.jp
Slave
ns1.bbb.co.jp
ns2.bbb.co.jp
・9.18.28
Master
ns0-2024.bbb.co.jp
Slave
ns1-2024.bbb.co.jp
ns2-2024.bbb.co.jp
# dig @ns1-2024.bbb.co.jp ns2.bbb.co.jp.
; <<>> DiG 9.18.28 <<>> @ns1-2024.bbb.co.jp ns2.bbb.co.jp.
; (1 server found)
;; global options: +cmd
;; Go
173.245.59.231 is a cloudflare name server.
I get this:
dig ns socialinnovation.ca
; <<>> DiG 9.16.50-Debian <<>> ns socialinnovation.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29081
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITI
On 2024-09-19 19:17, Mark Andrews wrote:
I think the reason for the REFUSED is pretty obvious
% dig +norec google._domainkey.socialinnovation.ca @173.245.59.231 txt
; <<>> DiG 9.21.0-dev <<>> +norec google._domainkey.socialinnovation.ca
@173.245.59.231 txt
;; global options: +cmd
;; Got answer
Thanks,
so patience is really the name of the game here. )
One more question, if I may - I noticed that the serial number in signed
zone gets 'out-of-sync' compared to my source text zone file. I guess
that happens when Bind publishes CDS / CDNSKEY records etc.
Is the serial number in my so
These are authoritative servers and the other domain is out of bailiwick, see
minimal-responses:
https://bind9.readthedocs.io/en/v9.18.30/reference.html#namedconf-statement-minimal-responses
Anyway any extra records are going to be thrown away by any DNS resolver
following the protocol,
so ther
On 03.10.24 09:21, 大浦 義 wrote:
・9.9.4→OK
# dig @ns1.bbb.co.jp time1.aaa.ne.jp
;; ANSWER SECTION:
time1.aaa.ne.jp. 3600IN CNAME ns2.bbb.co.jp.
ns2.bbb.co.jp. 900 IN A 1.2.3.5
;; AUTHORITY SECTION:
bbb.co.jp. 900 IN NS ns6-tk02.ccc.a
Thanks
・9.9.4→OK
# dig @ns1.bbb.co.jp time1.aaa.ne.jp
; <<>> DiG 9.18.28 <<>> @ns1.bbb.co.jp time1.aaa.ne.jp
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45310
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 2
;;
On 03.10.24 08:40, 大浦 義 wrote:
Referencing by cname from one authoritative zone to another authoritative zone
may not work properly depending on the version.
Is this due to a specification change? Is there a way to handle this?
I am running nslookup from a client that is not included in acl resp
Dear All
Referencing by cname from one authoritative zone to another authoritative zone
may not work properly depending on the version.
Is this due to a specification change? Is there a way to handle this?
I am running nslookup from a client that is not included in acl respectively.
I would like
12 matches
Mail list logo
