Question about authoritative server and AA Authoritative Answer

Wed Jan 17 15:00:23 UTC 2024

Hi again.
Please start a packet capture on the auth server. This should do it:
   sudo tcpdump -nvi any -c 10000 -w mydns.pcap port 53
Then from pc1, please do these and copy/paste text output, not screenshots:

dig @172.16.0.254 pc1.reseau1.lan NS +norecurse
dig @172.16.0.254 pc1.reseau1.lan SOA +norecurse
dig @172.16.0.254 pc1.reseau1.lan A +norecurse
dig @172.16.0.254 pc1.reseau1.lan AAAA +norecurse

Now stop the packet capture on the auth server and send all the information.

The reason for using @<IP_address> with dig is to eliminate the stub
resolver on pc1 itself.

Thanks, Greg

On Wed, 17 Jan 2024 at 12:59, <pub.diemer29 at laposte.net> wrote:

> ‌
> ‌
> Dear Greg,
> Dear Mark,
>
> Once more thank you for your replies. Please see highlighted words below.
>
> I confirm that 172.16.0.254 is the dns authoritative server.
>
>  'pc1' means 'a generic computer on a local area network'. It could be a
> web server, a file server, a mail server. For a small structure with fixed
> ip addresses only, it could be a user's pc. On pc1 there is a fresh install
> of ubuntu 22.04 with only a few network settings (dhcp, dns, gateway). I
> created it only to test various network settings (dynamic dns, fixed ip
> address, dhcp provided ip address, ...).
>
> For this specific question about authoritative server, pc1 has a fixed ip
> address. Ubuntu's networkd-resolved local dns caching and stub is disabled,
> (Cache=no, DNSStubListener=no). For this specific question, I have only
> two computers, one authoritative non-recursive dns server and a generic
> computer named pc1.
>
>
> Please have a look at the highlighted text below to understand my question
> :
>
> Command dig pc1.reseau1.lan *ns*
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> *AUTHORITY: 1 : this is ok.*
>
>
> Command dig pc1.reseau1.lan
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> *Why AUTHORITY: 0 and not AUTHORITY: 1 ???*
>
> De : "Greg Choules" <gregchoules+bindusers at googlemail.com>
> A : pub.diemer29 at laposte.net,bind-users at lists.isc.org
> Envoyé: lundi 15 Janvier 2024 18:27
> Objet : Re: Question about authoritative server and AA Authoritative Answer
>
> Hi again and thanks for that.
> I'm still not exactly clear on the setup. I think the auth server is
> 172.16.0.254 (I don't know what pc1 is).
> But anyway, looking at your results I see the AA bit for everything. It
> appears that these queries both went directly to the auth server because
> recursion is disabled and it told you so.
>
> ======
>
> # pc1 at pc1:~
> dig pc1.reseau1.lan
> ```
>
> ```txt
> ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> # ns1 at ns1:~
> dig pc1.reseau1.lan
> ```
>
> ```txt
> ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ======
>
> So unless I'm missing something I don't see your problem.
> Cheers, Greg
>
> On Mon, 15 Jan 2024 at 15:24, <pub.diemer29 at laposte.net> wrote:
>
>> D‌ear Greg,
>>
>> Thank you for your reply.
>>
>>
>> Please find attached the markdown file  with all the commands and text
>> from the terminal.
>>
>> In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener
>> from systemd-resolved. I have netplan and networkd.
>>
>>
>> Kind Regards,
>>
>> Michel Diemer.
>>
>>
>>
>> De : "Greg Choules"
>> A : pub.diemer29 at laposte.net,bind-users at lists.isc.org
>> Envoyé: dimanche 14 Janvier 2024 23:28
>> Objet : Re: Question about authoritative server and AA Authoritative
>> Answer
>>
>> Hi Michel.
>> Please can you send the following information:
>> - name and IP address of the authoritative server
>> - the full contents of the zone file for "reseau1.lan"
>> - name and IP address of the other server - what does this server do?
>> - What is the machine "pc1", on which you are running the digs?
>> - the file "/etc/resolv.conf" on "pc1"
>>
>> Please also re-send the digs with full output.
>> When you send information, please send it as text, not screenshots.
>>
>> Thanks, Greg
>>
>> On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users <
>> bind-users at lists.isc.org> wrote:
>>
>>> ‌Ders bind users,
>>>
>>> I have already asked a similar question which was more about DNS in
>>> general , this one is very specific about the AA bit.
>>>
>>> Today's question is : *« "dig pc1.reseau1.lan ns"** show AUTHORITY: 1
>>> and "dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am
>>> I missing ? If possible, how to get AA answers for QNAME queries ? »*
>>>
>>> I have set up two virtual machines on a virtual local network using
>>> Oracle VirtualBox. One machine is a DNS authoritative-only server. The
>>> zone is named "reseau1.lan" and defined only in bind9 zone files. If I
>>> really have to, I will name it "reseau1.home.arpa" according to RFC 8375.
>>> (I chose .lan inspired by RFC 6762 appendix G). The IP address of the DNS
>>> server is 172.16.0.254 and the IP address of pc1 is 172.16.0.21.
>>>
>>>
>>> *dig soa reseau1.lan* : the AA bit is set, which is what I am looking
>>> for
>>>
>>> ͏‌ ͏‌ ͏‌
>>>
>>> * dig pc1.reseau1.lan ns* :  the AA bit is set
>>>
>>> ͏‌ ͏‌ ͏‌ ͏‌
>>>
>>> *dig pc1.reseau1.lan* : *the AA bit is not set. Why ? Which setting or
>>> knowledge am I missing ?*
>>>
>>>
>>>
>>> Below my "named.conf.options" file
>>>
>>> ͏‌
>>>
>>>
>>> ͏‌ ͏‌ ͏‌ ͏‌
>>> --
>>> 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 at lists.isc.org
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240117/f5c21ee9/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5400853000000119embeddedImage
Type: image/png
Size: 5348 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240117/f5c21ee9/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6206303000000119embeddedImage
Type: image/png
Size: 5427 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240117/f5c21ee9/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8504625embeddedImage
Type: image/png
Size: 8645 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240117/f5c21ee9/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 13119901000000238embeddedImage
Type: image/png
Size: 6496 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240117/f5c21ee9/attachment-0007.png>