l-response" option is not the one controlling whether or not both CNAME and A are turned by dig, right ?
Thanks,
Veronique
From: Ondřej Surý
Sent: Monday, October 31, 2022 5:30 PM
To: BIND users
Cc: Veronique Lefebure
Subject: Re: dig +norecurse behaviour changed with 9.16.33
Since we
onday, October 31, 2022 5:30 PM
To: BIND users
Cc: Veronique Lefebure
Subject: Re: dig +norecurse behaviour changed with 9.16.33
Since we have already established that this is not a **dig** issue, you might
want
to look at the `minimal-responses` option. The default has changed from `no` to
`no-auth-rec
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
Since we have already established that this is not a **dig** issue, you might
want
to look at the `minimal-responses` option. The default has changed from `no` to
`no-auth-recursive` in 9.12.0
Anyway, the 9.16.0 is doing the right thing because there's a zone cut between
the two names, any resolv
Hi Veronique.
I'm not an expert, but to me the 9.16 behaviour is what I would expect
to happen, based on:
* When you issue the non-recursive query for "spectrum.cern.ch", it is
answered from the "cern.ch" zone, which only knows the CNAME
(returned in the ANSWER section) and the NS recor
Hi Veronique.
As Petr said, please don't send a pcap. This is getting beyond the scope of
the list and into proper support territory. For which I would recommend
that CERN pay ISC for professional support services.
Regarding your external example, I get this:
%dig @192.65.187.5 foundservices.cern.
Are the zones cern.ch and spectrum-lb.cern.ch on the same authoritative
sDNS server?
--
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/ fo
Hello,
please see answer in-line:
On 27. 10. 22 14:28, Veronique Lefebure wrote:
(*) 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 ANS
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.
an
On 27.10.22 09:08, Veronique Lefebure wrote:
yes, here is a concrete example:
# ip-dns-1 runs BIND 9.16.33:
dig @ip-dns-1 spectrum.cern.ch +short +norecurse
spectrum-lb.cern.ch. <- Here we get only the CNAME
# ip-dns-0 runs BIND 9.11:
dig @ip-dns-0 spectrum.cern.ch +short +n
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 everyth
Hi all,
yes, here is a concrete example:
# ip-dns-1 runs BIND 9.16.33:
dig @ip-dns-1 spectrum.cern.ch +short +norecurse
spectrum-lb.cern.ch. <- Here we get only the CNAME
# ip-dns-0 runs BIND 9.11:
dig @ip-dns-0 spectrum.cern.ch +short +norecurse
spectrum-lb.cern.ch.
xxx
Or cache snooping behaves differently between two (or multiple) queries.
That’s why questions like this should not imply where the problem is but rather
describe what can be seen (possibly also on the wire).
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be dif
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.
as others have said, this needs more details, but I wonder whether you might
now be querying a server which has
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, u
For both versions of bind, please submit the actual dig command and the
complete results received. That will make diagnosing this issue MUCH easier.
Regards,
Bob
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software
I am unable to reproduce this. Please share some examples like this:
dig +norecurse @216.239.34.110 www.lathama.org
```
; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> +norecurse @216.239.34.110
www.lathama.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY,
You need to be more specific with real examples.
Ondrej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel
obligated to reply outside your normal working hours.
> On 26. 10. 2022, at 17:41, Veronique Lefebure
> wrote:
>
>
> Hi,
>
>
18 matches
Mail list logo
