It seems to me this is a very similar question to previous thread named:
Classless reverse zones CNAME and PTR resolution issue
When your query does not request recursion then CNAME is not followed to
other zones by authoritative server. For iterative recursive servers, be
it bind9, unbound or similar, this is not a problem. The answer points
where to follow. Another non-recursive query to spectrum-lb subdomain is
required.
That is change done on 9.16.x and later. Any standards following
implementation should handle it well.
May I ask why is this change considered a problem? If it did break
anything then I assume the fix should be done elsewhere, not on bind9
side. Is there any recursive resolver which is not able to follow such
answers and to deliver final result to asking clients? Were you solving
this difference just for curiosity or did it break something not yet
mentioned?
Regards,
Petr
On 27. 10. 22 14:28, Veronique Lefebure wrote:
Well,
So here a bit more details.
Sorry, I cannot take an example with a DNS server accessible to you
(*) because they have all been upgraded to 9.16.
The .cern.ch contains:
spectrum-lb IN NS ip-dns-1.cern.ch.
spectrum-lb IN NS ip-dns-2.cern.ch.
spectrum IN CNAME spectrum-lb.cern.ch.
and
spectrum-lb.cern.ch contains:
$ORIGIN .
$TTL 60 ; 1 minute
spectrum-lb.cern.ch IN SOA ip-dns-1.cern.ch. internal-dns.cern.ch. (
273 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
3600000 ; expire (5 weeks 6 days 16 hours)
60 ; minimum (1 minute)
)
NS ip-dns-1.cern.ch.
NS ip-dns-2.cern.ch.
A xxx.xxx.xx.140
named configuration file is identical between 9.11 and 9.16 except for
the following options that we have added for 9.16:
#BIND916 options
qname-minimization disabled;
stale-answer-enable no;
stale-refresh-time 0; #default is 30
max-stale-ttl 1w;
dnssec-policy none;
synth-from-dnssec no;
min-cache-ttl 0;
min-ncache-ttl 0;
minimal-responses no;
(*) On an external DNS server you can try with the following similar
case:
Running DiG 9.11.21 on a linux client
ext-dns-1 (192.65.187.5) runs BIND9.16:
dig @ext-dns-1 foundservices.cern.ch | grep flags | grep ANSWER
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
dig @ext-dns-1 foundservices.cern.ch *+norecurse* | grep flags | grep
ANSWER
;; flags: qr aa ra; QUERY: 1, ANSWER: *1*, AUTHORITY: 0, ADDITIONAL: 1
Full output:
dig @192.65.187.5 foundservices.cern.ch +norecurse
; <<>> DiG 9.11.21 <<>> @192.65.187.5 foundservices.cern.ch +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9899
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8786b980a1a80a7901000000635a7898a512a21aa6138faf (good)
;; QUESTION SECTION:
;foundservices.cern.ch. IN A
;; ANSWER SECTION:
foundservices.cern.ch. 900 IN CNAME db-lb-1234.cern.ch.
;; Query time: 2 msec
;; SERVER: 192.65.187.5#53(192.65.187.5)
;; WHEN: Thu Oct 27 14:24:56 CEST 2022
;; MSG SIZE rcvd: 103
ip-dns-0 runs BIND9.11:
dig @ip-dns-0 foundservices.cern.ch | grep flags | grep ANSWER
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4
dig @ip-dns-0 foundservices.cern.ch *+norecurse* | grep flags | grep
ANSWER
;; flags: qr aa; QUERY: 1, ANSWER:*2*, AUTHORITY: 2, ADDITIONAL: 4
Does that help ?
Greg, can I send you a pcap file in a private email ?
Thanks,
Veronique
On 27/10/2022 10:09 Greg Choules
<gregchoules+bindus...@googlemail.com> wrote:
Hi Veronique.
No, we cannot easily reproduce this behaviour because we have no
knowledge of the configs of either of those servers, the details of
the zones you have configured, the contents of those zones or of the
system on which you are running the dig command.
As I said, we need to see everything please:
- Full digs, not +short
- you have specified @ip-dns0 and @ip-dns1 - the full configs of both
of those servers please, including zone definitions and contents for
where "spectrum.cern.ch <http://spectrum.cern.ch/>" lives as it is
not a name that can be resolved from the public Internet
- a binary pcap file, using the -w option of tcpdump, capturing all
port 53 traffic (UDP and TCP) between this machine and both DNS servers.
By the way, when using the @<server> option of dig please use
explicit IP addresses, not names. If you use a name, then dig first
has to resolve that name and the place it will go to do that is
resolv.conf. So it is now dependent on your system DNS setup to get
an IP address to send the dig to.
Also, you have specified @<simple_host_name> not @<FQDN>. This
suggests to me that in resolv.conf you have a 'search' list.
Personally I don't like search lists because they potentially
increase the workload of the DNS system generally, lengthen query
times and mean that you can't be sure exactly where an answer came from.
Thanks, Greg
On Thu, 27 Oct 2022 at 08:08, Veronique Lefebure
<veronique.lefeb...@cern.ch> wrote:
Hi all,
yes, here is a concrete example:
# ip-dns-1 runs BIND 9.16.33:
dig @ip-dns-1 spectrum.cern.ch <http://spectrum.cern.ch> +short
+norecurse
spectrum-lb.cern.ch <http://spectrum-lb.cern.ch>.
<------------- Here we get only the CNAME
# ip-dns-0 runs BIND 9.11:
dig @ip-dns-0 spectrum.cern.ch <http://spectrum.cern.ch> +short
+norecurse
spectrum-lb.cern.ch <http://spectrum-lb.cern.ch>.
xxx.xxx.xx.140 <-------- Here we get in addition the IP
of spectrum-lb.cern.ch <http://spectrum-lb.cern.ch>.
And yes, a capture shows confirms indeed that dig returns less
information when the BIND 9.16.33 DNS server is used.
I guess you can easily reproduce that behaviour, unless it is due
to a mis-configuration bit on our DNS server ?
Thanks,
Véronique
On 26/10/2022 21:04 Greg Choules
<gregchoules+bindus...@googlemail.com
<mailto:gregchoules%2bbindus...@googlemail.com>> wrote:
Hi Veronique.
As other people have said, more details please.
To have a complete picture of what is going on, not only would
we need to know what your dig tests look like, but also where
dig is sending its queries and how that DNS server is configured.
You can tell dig to send queries anywhere, using @<server>.
However, if you don't use that it will default to using the
nameservers in /etc/resolv.conf. So it may be useful to see the
contents of that.
Wherever dig is sending its queries, we would need to know what
that server will do with them. So its configuration would also
be useful.
Lastly, the best way to see queries and responses, right down to
the nuts and bolts, is with a packet capture.
You thought this was an easy question, huh ;)
Can you provide at least some of these things, to get started?
Cheers, Greg
On Wed, 26 Oct 2022 at 16:41, Veronique Lefebure
<veronique.lefeb...@cern.ch> wrote:
Hi,
dig answer is different between BIND 9.11 and BIND 9.16(.33)
when +norecurse option is used.
Is this documented somewhere ?
Is there an option that needs to be set so that the
behaviour of 9.16 is the same as the one in 9.11.
The change is that with 9.16, if the requested name is a
CNAME, only the CNAME value is returned by dig, while with
9.11 dig would return both the CNAME value and the IP of the
CNAME.
Thanks,
Veronique
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list
ISC funds the development of this software with paid support
subscriptions. Contact us at https://www.isc.org/contact/
for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
