Score:-1

Server

DNS lookup fails if provided domain name ends with a slash

Thomas Popp

12/21/23, 3:43 PM

We have successfully run an office network with various Linux servers (Ubuntu) and Windows+Linux clients for several years now. One server acts as and internal DNS server using the DNSmasq light-weight DNS server package.

And just today I found out that the command
$ nslookup machine.domain.com works, but
$ nslookup machine.domain.com/ does NOT work --> Non-existent domain / NXDOMAIN

This happened on an Ubuntu machine as well as on a Windows machine.

Is this just because here (i.e. when using cmds like "nslookup" or "host"), the slash at the end is considered being part of the domain name, i.e. top-level domain being "com/"? Or does it indicate some misconfiguration of our internal DNS server?

Obviously, browsers "usually" handle this slash correctly in the sense that they use just the domain name without the slash for DNS lookup and thus get an answer. I put the "usually" here because just today I came across a fresh Firefox installed on a fresh Ubuntu 22.04 LTS installation where entering the slash in the browser address bar (i.e. machine.domain.com/) strangely ended with the NXDOMAIN error message mentioned above.

And - even stranger - only after a successful lookup by removing the trailing slash, it also started to work with the "slashed address". This latter behavior might be caused by Firefox caching...

Anyone having some insights for me? Is it maybe even a combination of my missing understanding how DNS works (i.e. a trailing slash or even a subsequent path actually really points to a "different domain") and a Firefox bug (i.e. erroneously including the slash in the DNS query in the installed Firefox version)? Thanks!

278

2 + 2

domain-name-system

internal-dns

nameserver

dns-lookup

joeqwerty

12/21/23, 4:11 PM

**Is this just because here (i.e. when using cmds like "nslookup" or "host"), the slash at the end is considered being part of the domain name, i.e. top-level domain being "com/"?** - Yes. Don't do that.

Thomas Popp

12/22/23, 11:56 AM

Thanks! Now I understand (still, I have no clue what problem Firefox had, which actually made me try the DNS lookup with a trailing slash ... I just thought nslookup would also strip it like browsers do ... anyway, I don't care about the Firefox issue any more). But why didn't you post an answer? I would have marked it as the correct one! And it is right to the point (and not insulting or lecturing me ;-)

Score:1

Server

proxx

12/21/23, 3:54 PM

As mentioned here link (microsoft) domains can only contain alphabetical characters, digits and the '-' symbol.

Anything else is not legal(Not true, rightfully corrected by @Patrick Mevzek), nslookup will probably not parse this or your DNS server rightfully rejects such a silly request :)

Whatever happens in your webbrowser after the slash is not part of DNS and nslookup does not understand this.

curl for example won't complain and just see's this as the root of the webserver.

curl example.com/                           
<!doctype html>
<html>
<head>
    <title>Example Domain</title>

+ 6

Patrick Mevzek

12/21/23, 7:30 PM

"Anything else is not legal," No, that is only half true or plain wrong depending how you see it. The DNS has domain names, which are "any characters". A subset of those are called hostnames and are LDH aka letters digits hyphens. Some records can be only on hostnames, like A/AAAA and some records can be on domain names, or both, like TXT, CNAME, etc. `nslookup`, like `dig` is probably doing by default a lookup for type `A`, so it means hostnames. But in general the DNS allows any characters.

Patrick Mevzek

12/21/23, 7:32 PM

"curl for example won't complain" Because `curl` in an HTTP client, so `example.com/` is just considered as `http://example.com/` which is a full URL to request resource `/` on website `example.com` through the HTTP protocol.

proxx

12/21/23, 8:30 PM

Obvious over simplifications matching the level of the one asking the question. But sure.

Thomas Popp

12/22/23, 11:48 AM

Thanks for the answer (but not for judging my level so easily, proxx ;-) You are right, I could have had a look in a standard/specification before. But what I can tell you for sure (and what I described in my post) is that at least the nslookup's I tested on Ubuntu 18.04 and Windows 11 happily parses my "silly request". And our DNS server as I now understand correctly answers with NXDOMAIN. Thanks again, but I will not mark this as the correct answer because of the unkindness and prejudice.

Patrick Mevzek

12/23/23, 12:21 AM

@proxx, no you don't simplify, you are telling wrong things. "anything else is not legal" is not true.

proxx

12/23/23, 7:57 AM

I corrected my statement and referred to you in the post, thanks Patrick!

Score:0

Server

Oneiroi

12/21/23, 4:01 PM

You're mixing standards; the use of a "forward slash" is correct for the Hyper Text Transfer Protocol (HTTP).

A HTTP compliant address forms from, a protocol definition, followed by a Fully Qualified Domain name (FQDN) and the Uniform Resource Indicator (URI).

e.g. https://sub.domain.tld/uri/of/the/resource/being/requested

Protocol: https (TLS encapsulated HTTP Protocol) FQDN: sub.domain.tld URI: /uri/of/the/resource/being/requested

Where as, DNS is only intended to resolve the FQDN to the ip address to be reached, e.g.

FQDN: one.one.one.one ipv4: 1.1.1.1

The Top Level Domain, is a part of the FQDN namely the last part following the . separator, e.g. .com .co.uk .site etc ...

In short the reason that any domains being passed to nslookup fails to resolve is as the / is interpreted literally, whilst any browser recognises for what is is; one of the parts of the HTTP protocol.

nslookup attempts to resolve sub.domain.tld/, and any browser will "chuck" up the input into the FQDN sub.domain.tld and the URI /

Hopefully this lends some clarity

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: DNS lookup fails if provided domain name ends with a slash

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.