Change in behaviour regarding ndots and searchlist

Lightner, Jeff JLightner at dsservices.com
Mon Sep 15 12:29:22 UTC 2014


I've begun seeing this recently in nslookup on Windows workstations as well.    It appears it is appending search domains even when I've specified an FQDN.   That is I have two search domains such as ex1.com and ex2.net and I typed short name "ralph" for nslookup or host it would give me "ralph.ex1.com" IP if it existed or "ralph.ex2.net" if the ralph.ex1.com didn't exist and the latter did.   Now what I'm seeing is even if I specify "ralph.ex1.com" it is looking up and failing on "ralph.ex1.com.ex2.net".

If I put a dot at the end of the FQDN (e.g. ralph.ex1.com. instead of just ralph.ex1.com) it doesn't do that.    The Windows admins recently built a couple of new domain controllers for Windows DNS so I assumed it had something to do with those.   Do you by any chance have Windows DNS in your environment?

There was an article posted last week to this forum regarding bleed over of internal domains to the internet and vice-versa when one is using a domain internally that might be registered to someone else externally which is the case in our environment.    It may also be that the issue is because the formerly externally registered domain appears to have gone to expired/renewal status recently and it may be the Registrar is somehow causing this bleed over effect in the way they present records.




-----Original Message-----
From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Mark Andrews
Sent: Monday, September 15, 2014 5:16 AM
To: BIND Users
Subject: Re: Change in behaviour regarding ndots and searchlist


Partially qualified names are DANGEROUS.  You realy do not want to use them ever no matter how convient or useful they appear to be.

In message <20140915083532.GA29404 at danton.fire-world.de>, Sebastian Wiesinger w
rites:
> Hello,
>
> I noticed a change in the host tool in regard to how searches are done
> when there are >= "ndots" dots in the query. In the following case
> ndots is always nonexistant in the configuration.
>
> With bind 9.8 (Debian 1:9.8.4.dfsg.P1):
>
> $ host -d test.example
> Trying "test.example"
> Received 105 bytes from 127.0.0.1#53 in 6 ms Trying
> "test.example.office.example.com"
> Trying "test.example.backup.example.org"
> Trying "test.example.example.com"
> Trying "test.example.example.org"
> Trying "test.example.winzone.example.com"
> Trying "test.example.nms.example.com"
> Host test.example not found: 3(NXDOMAIN) Received 104 bytes from
> 127.0.0.1#53 in 1 ms
>
>
> With bind 9.9 (Debian 1:9.9.5.dfsg-4~bpo70, same on Ubuntu
> 1:9.9.5.dfsg-3):
>
> $ host -d test.example
> Trying "test.example"
> Host test.example not found: 3(NXDOMAIN) Received 105 bytes from
> 127.0.0.1#53 in 15 ms Received 105 bytes from 127.0.0.1#53 in 15 ms
>
>
> So with "host" from bind 9.8 the absolute name is tried first and
> after that the search list is tried.
>
> With bind 9.9 this is no longer the case.
>
> Does anyone know if that was a deliberate change? I liked the old
> behaviour because I could search for internal subdomains without
> specifying/knowing the full FQDN.
>
> As a workaround I raised the ndots value to 2 but that increases the
> number of queries because the searchlist is tried first for things
> like linux.org. Also it increases the potential for MITM as
> "linux.org.example.com." is tried first.
>
> Regards
>
> Sebastian
>
> --
> GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A  9D82 58A2 D94A 93A0
> B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS
> NOTICE THE SCYT HE.
>             -- Terry Pratchett, The Fifth Elephant
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe  from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Athena(r), Created for the Cause(tm)
Making a Difference in the Fight Against Breast Cancer

__________________________________________________________
CONFIDENTIALITY NOTICE: This e-mail may contain privileged

or confidential information and is for the sole use of the intended

recipient(s). If you are not the intended recipient, any disclosure,

copying, distribution, or use of the contents of this information

is prohibited and may be unlawful. If you have received this electronic

transmission in error, please reply immediately to the sender that

you have received the message in error, and delete it. Thank you


More information about the bind-users mailing list