[dns-operations] Single label queries on Windows (11)
David Conrad
drc at virtualized.org
Sat Jul 8 19:36:12 UTC 2023
A very long time ago (i.e., back when I was executive director of ISC and BINDv9.0.0 was being released) we tried to encourage people to NOT use nslookup as it tends to try too hard to “help", leading to all sorts of confusion, e.g., the kind you experienced. Instead, we recommended dig as (a) it provides all sorts of options that help with pretty much every form of diagnostic you can imagine and (b) it doesn’t try to “help”. We obviously didn’t succeed and it’s far too late now (it was back then too). Ah well…
Regards,
-drc
> On Jul 7, 2023, at 10:35 PM, Petr Menšík <pemensik at redhat.com> wrote:
>
> Ah, this is embarrassing. Yes, trailing dot have helped.
>
> I am sorry for the confusion.
>
>
> >nslookup -type=ns org.
> Server: pihole
> Address: 192.168.88.9
>
> Non-authoritative answer:
> org nameserver = b2.org.afilias-nst.org <http://b2.org.afilias-nst.org/>
> org nameserver = a2.org.afilias-nst.info <http://a2.org.afilias-nst.info/>
> org nameserver = c0.org.afilias-nst.info <http://c0.org.afilias-nst.info/>
> org nameserver = b0.org.afilias-nst.org <http://b0.org.afilias-nst.org/>
> org nameserver = a0.org.afilias-nst.info <http://a0.org.afilias-nst.info/>
> org nameserver = d0.org.afilias-nst.org <http://d0.org.afilias-nst.org/>
>
> a0.org.afilias-nst.info <http://a0.org.afilias-nst.info/> internet address = 199.19.56.1
> a2.org.afilias-nst.info <http://a2.org.afilias-nst.info/> internet address = 199.249.112.1
> b0.org.afilias-nst.org <http://b0.org.afilias-nst.org/> internet address = 199.19.54.1
> b2.org.afilias-nst.org <http://b2.org.afilias-nst.org/> internet address = 199.249.120.1
> c0.org.afilias-nst.info <http://c0.org.afilias-nst.info/> internet address = 199.19.53.1
> d0.org.afilias-nst.org <http://d0.org.afilias-nst.org/> internet address = 199.19.57.1
> a0.org.afilias-nst.info <http://a0.org.afilias-nst.info/> AAAA IPv6 address = 2001:500:e::1
> a2.org.afilias-nst.info <http://a2.org.afilias-nst.info/> AAAA IPv6 address = 2001:500:40::1
> b0.org.afilias-nst.org <http://b0.org.afilias-nst.org/> AAAA IPv6 address = 2001:500:c::1
> b2.org.afilias-nst.org <http://b2.org.afilias-nst.org/> AAAA IPv6 address = 2001:500:48::1
> c0.org.afilias-nst.info <http://c0.org.afilias-nst.info/> AAAA IPv6 address = 2001:500:b::1
> d0.org.afilias-nst.org <http://d0.org.afilias-nst.org/> AAAA IPv6 address = 2001:500:f::1
>
>
> On 7/7/23 20:32, Viktor Dukhovni wrote:
>> On Fri, Jul 07, 2023 at 08:09:39PM +0200, Petr Menšík wrote:
>>
>>> I have tested recently how Windows 11 behaves when resolving single
>>> label queries.
>>>
>>> I have expected it might try to use LLMNR. But I did not expect it would
>>> do so also when trying nslookup, a tool which should be DNS only tool.
>>>
>>> I have tried:
>>>
>>> nslookup -type=ns com 9.9.9.9
>> It is not too surprising if this is also subject to the default suffix
>> list of the network "connection", which initialises the resolution
>> context, and then just overrides the server. Have you tried:
>>
>> nslookup -type=ns com. 9.9.9.9
>>
>> with an explicit trailing "."?
> I thought I have tried that, but turns out I have tried that only when
> testing behavior of systemd-resolved installation on Linux, where it was useless.
> On Windows it helps. Parameter -debug showed it indeed
> appends default domain suffix and does not try without it after negative
> response.
>
> nslookup from ISC BIND9 behaves a bit better, but that is an acceptable difference.
>
> $ nslookup -domain=home.arpa -debug -type=ns org
>
> Server: 127.0.0.1
> Address: 127.0.0.1#53
>
> ------------
> QUESTIONS:
> org.home.arpa, type = NS, class = IN
> ANSWERS:
> AUTHORITY RECORDS:
> -> home.arpa
> origin = localhost
> mail addr = nobody.invalid
> serial = 1
> refresh = 3600
> retry = 1200
> expire = 604800
> minimum = 10800
> ttl = 10800
> ADDITIONAL RECORDS:
> ------------
> ** server can't find org.home.arpa: NXDOMAIN
> Server: 127.0.0.1
> Address: 127.0.0.1#53
>
> ------------
> QUESTIONS:
> org, type = NS, class = IN
> ANSWERS:
> -> org
> nameserver = b0.org.afilias-nst.org.
> ttl = 1824
> -> org
> nameserver = b2.org.afilias-nst.org.
> ttl = 1824
> -> org
> nameserver = c0.org.afilias-nst.info.
> ttl = 1824
> -> org
> nameserver = d0.org.afilias-nst.org.
> ttl = 1824
> -> org
> nameserver = a0.org.afilias-nst.info.
> ttl = 1824
> -> org
> nameserver = a2.org.afilias-nst.info.
> ttl = 1824
> AUTHORITY RECORDS:
> ADDITIONAL RECORDS:
> ------------
> Non-authoritative answer:
> org nameserver = b0.org.afilias-nst.org.
> org nameserver = b2.org.afilias-nst.org.
> org nameserver = c0.org.afilias-nst.info.
> org nameserver = d0.org.afilias-nst.org.
> org nameserver = a0.org.afilias-nst.info.
> org nameserver = a2.org.afilias-nst.info.
>
> Authoritative answers can be found from:
>
>>> Got NXDOMAIN. I were very suprised, learned that does not exist. Even
>>> more suprising were fact, that it presented the result came from the
>>> specified server.
>> But the result should have been for "com.<your-default-suffix>."
>> What happens when you configure the network connection with a default
>> suffix of "."?
> "nslookup -domain=. -type=ns com" works fine as well.
> --
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, https://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230708/ce232812/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20230708/ce232812/attachment-0001.sig>
More information about the dns-operations
mailing list