[AusNOG] DNS Devolution targeting the .com.au space - should we be worried?
Nick Marsham
nick at c2conline.com.au
Mon Jun 5 15:38:04 EST 2017
Mark, I completely agree with you: Partially qualified names are awful, and Windows' DNS implementation leaves a bit to be desired, however it's important to note a few things here, still, related to the original query:
DNS devolution in Microsoft land is controlled on a client level, and the client will never append a search suffix that is any shorter than the Forest Root Domain unless it is otherwise specified by policy. DNS devolution is completely disabled if the FRD does not match the primary DNS suffix of the querying machine. This is about a sane an implementation of searching a suffix list as I can think of, and it has been the case since 2009.
You can manually specify a devolution level of as low as 2 in order to see terrible behaviour exhibited, and that would be stupid and your own fault -- but I've seen it done in some legacy environments because some legacy Windows environments are eldritch horrors that require blood sacrifice in order to function.
Obviously any company using a valid, ICANN-approved FQDN should have that domain registered, and all internal domain-joined client machines should only use DCs for DNS whenever in the perimeter. I have no sympathy for anyone who is using a valid FQDN for their AD domain that is owned by a third party.
All of that said, `nslookup` varies significantly from the Windows API's `getaddrinfo` method. In a general sense, `nslookup` is a completely different DNS client to Windows' creatively named `DNS Client`. Relying on the output of `nslookup` to tell you what `DNS Client` is doing can and will lead you down a garden path. Implement a one-line console app that uses `getaddrinfo` and pcap it -- you'll probably find that in practise Windows doesn't perform as silly DNS devolution as you might think.
Cheers,
Nick.
-----Original Message-----
From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of Mark Andrews
Sent: Monday, 5 June 2017 2:46 PM
To: Mark Smith <markzzzsmith at gmail.com>
Cc: <ausnog at lists.ausnog.net> <ausnog at lists.ausnog.net>
Subject: Re: [AusNOG] DNS Devolution targeting the .com.au space - should we be worried?
In message <CAO42Z2yUeCWoYXxODcpkFtHO4rNxDygjcBxjrrq7jRbHvvgjCg at mail.gmail.com>
, Mark Smith writes:
>
> What you're seeing is quite expected, you're providing a relative
> domain name not an absolute one. Since it is relative, then the DNS
> resolver will try to use the list of search domains it has to resolve it.
>
> The purpose of providing a domain to a client e.g. via DHCP is so that
> relative names can be used for things.
>
> In the ISP world, it would be so that customers can type "mail" rather
> than "mail.isp.com". I don't think that is really much value anymore,
> as the only place people commonly type domain names its into their web
> browser, and they're full domain names outside the ISP's name space,
> even though they're technically not fully qualified - a fully
> qualified domain name has a dot on the end e.g. "mail.isp.com.". Also,
> ISPs provide full (relative) names on settings pages too.
>
> So you have the following options
>
> (a) always use fully qualified domain names i.e. ones that have dots
> on the end - which is impractical because it will be hard to change
> end user behaviour.
>
> (b) work out where your resolver relative search list is and stop it
> listing .com.au. Something to try is to have a single search domain of
> '.', which would make all relative domain names absolute ones upon the
> first resolution attempt.
>
> Try your nslookup query with a dot on the end and it should either
> entirely succeed or entirely fail on the first resolution attempt.
This is also Microsoft ignoring security warnings and fixes that were issued and deployed 2+ decades ago. RFC 1535 first raised this and the search mechanism was changed to do queries with dots "as is", then apply the search list. Additionally the search list became a single element as it was realised that you couldn't just strip off leading labels safely.
I tried hard to argue that partially qualified names should no longer be a concept (if there is a period in the name then it is always treated as absolute). I also tried hard to argue that searches should stop on NODATA, that the only response that should cause a search to move onto the next element is NXDOMAIN. SERVFAIL should be terminal.
Remember periods at the end to indicate no searching is a local user interface issue as is searching itself. Domain elements in protocols are fully qualified and don't have a final period.
And before you mention DNS master files, there is no searching.
There is appending the current origin or not depending on the absence or not of the final period. There is no ambiguity that there is with searching. This is text based compression.
Also ISP's that depend on their domain being in the search list on customer machines are idiots. Search list are one of the things that hosts can override and you should never trust a search list given to you by a ISP or a hotspot.
Mark
> On 1 Jun. 2017 17:38, "Benjamin Ricardo" <ben.ricardo at acs.net.au> wrote:
>
> Ahh yes I hadn’t thought of the catchall.
>
>
>
> You are correct Nick there is still an old 2003 DC in this domain and
> yes since Win7 / Server2k8r2 the devolution level criteria has
> changed– this will have been the issue I guess.
>
> I thought the client controlled the DNS Devolution level though and
> these clients are Win10?
>
>
>
> Win10 client querying against a 2008R2 DNS Servers
>
>
>
> Example (you asked for it)
>
>
>
> PS C:\> nslookup
>
> Default Server: nameserver
>
> Address: 192.168.23.10
>
>
>
> > set debug
>
> > vpn.somedomain.com
>
> Server: nameserver
>
> Address: 192.168.23.10
>
>
>
> ------------
>
> Got answer:
>
> HEADER:
>
> opcode = QUERY, id = 2, rcode = NXDOMAIN
>
> header flags: response, auth. answer, want recursion,
> recursion avail.
>
> questions = 1, answers = 0, authority records = 1,
> additional = 0
>
>
>
> QUESTIONS:
>
> vpn.somedomain.com.somedomain.com.au, type = A, class = IN
>
> AUTHORITY RECORDS:
>
> -> somedomain.com.au
>
> ttl = 3600 (1 hour)
>
> primary name server = sterdevel.somedomain.com.au
>
> responsible mail addr = hostmaster. somedomain.com.au
>
> serial = 185662
>
> refresh = 900 (15 mins)
>
> retry = 600 (10 mins)
>
> expire = 86400 (1 day)
>
> default TTL = 900 (15 mins)
>
>
>
> ------------
>
> ------------
>
> Got answer:
>
> HEADER:
>
> opcode = QUERY, id = 3, rcode = NXDOMAIN
>
> header flags: response, auth. answer, want recursion,
> recursion avail.
>
> questions = 1, answers = 0, authority records = 1,
> additional = 0
>
>
>
> QUESTIONS:
>
> vpn. somedomain.com. somedomain.com.au, type = A, class = IN
>
> AUTHORITY RECORDS:
>
> -> somedomain.com.au
>
> ttl = 3600 (1 hour)
>
> primary name server = sterdevel. somedomain.com.au
>
> responsible mail addr = hostmaster. somedomain.com.au
>
> serial = 185662
>
> refresh = 900 (15 mins)
>
> retry = 600 (10 mins)
>
> expire = 86400 (1 day)
>
> default TTL = 900 (15 mins)
>
>
>
> ------------
>
> ------------
>
> Got answer:
>
> HEADER:
>
> opcode = QUERY, id = 4, rcode = NOERROR
>
> header flags: response, want recursion, recursion avail.
>
> questions = 1, answers = 1, authority records = 0,
> additional = 0
>
>
>
> QUESTIONS:
>
> vpn. somedomain.com.com.au, type = A, class = IN
>
> ANSWERS:
>
> -> vpn. somedomain.com.com.au
>
> internet address = 192.185.161.219
>
> ttl = 4021 (1 hour 7 mins 1 sec)
>
>
>
> ------------
>
> Non-authoritative answer:
>
> ------------
>
> Got answer:
>
> HEADER:
>
> opcode = QUERY, id = 5, rcode = NOERROR
>
> header flags: response, want recursion, recursion avail.
>
> questions = 1, answers = 0, authority records = 1,
> additional = 0
>
>
>
> QUESTIONS:
>
> vpn. somedomain.com.com.au, type = A, class = IN
>
> AUTHORITY RECORDS:
>
> -> com.com.au
>
> ttl = 900 (15 mins)
>
> primary name server = ns1255.websitewelcome.com
>
> responsible mail addr = root.harrier.websitewelcome.com
>
> serial = 2017051610 <(201)%20705-1610>
>
> refresh = 86400 (1 day)
>
> retry = 7200 (2 hours)
>
> expire = 3600000 (41 days 16 hours)
>
> default TTL = 86400 (1 day)
>
>
>
> ------------
>
> Name: vpn. somedomain.com.com.au
>
> Address: 192.185.161.219 <- this is the wrong
> address
>
>
>
> >
>
>
>
>
>
> *From:* Nick Marsham [mailto:nick at c2conline.com.au]
> *Sent:* Thursday, 1 June 2017 3:52 PM
> *To:* Benjamin Ricardo <ben.ricardo at acs.net.au>; 'Ausnog' <
> ausnog at lists.ausnog.net>
> *Subject:* RE: [AusNOG] DNS Devolution targeting the .com.au space -
> should we be worried?
>
>
>
> DNS devolution in AD domains in all supported versions of Windows
> doesn’t proceed past the FQDN of the forest root domain, so the only
> way you could get into this exact scenario is by your FRD configured
> as “com.au”, or to have a global search suffix list configured which
> includes the suffix “com.au”, since global search suffix lists override devolution.
>
>
>
> If you‘re able to provide me an example of how devolution could
> actually cause the scenario you suggest in Windows 7/Server 2008R2 or
> newer, I’d be very interested.
>
>
>
> It’s also important to note that the owner com.com.au is not
> explicitly “registering” A records in order to catch big-name
> companies: Their DNS server simply has a ‘catchall’ which returns a landing page.
>
>
>
> *From:* AusNOG [mailto:ausnog-bounces at lists.ausnog.net
> <ausnog-bounces at lists.ausnog.net>] *On Behalf Of *Benjamin Ricardo
> *Sent:* Thursday, 1 June 2017 3:36 PM
> *To:* 'Ausnog' <ausnog at lists.ausnog.net>
> *Subject:* [AusNOG] DNS Devolution targeting the .com.au space -
> should we be worried?
>
>
>
> HI All,
>
> Looking for thoughts on something that we uncovered today in the wild
> (heard about it years ago but never seen it) regarding internal
> company domains that are using public .com.au domain suffixes and
> whether there’s something that should be done here.
>
>
>
> The issue is caused by Microsofts Primary DNSSuffix Devolution and the
> potential for legitimate traffic to be redirected to the owner of the
> domain “com.com.au.” if your machine has a domain name of “
> somehostname.somedomainname.com.au”
>
> It is possible in this situation for a non-qualified query to do the
> following:
>
>
>
> ibm.com.somehostname.somedomainname.com.au (NXDOMAIN)
>
> ibm.com.somedomainname.com.au
> (NXDOMAIN)
>
> ibm.com.com.au
> (NOERROR)
>
>
>
> You can see the vulnerability.
>
> The problem is now that it appears that the owner of the domain
> “com.com.au”
> has started to register A records for big name domains such as
> .ibm.com in the hope of catching non-fully qualified queries to these addresses.
>
>
>
> I can only think that this is going to end badly for people.
>
> Is this the sort of thing that could be flagged as abuse?
>
>
>
> Appreciate any comments.
>
>
>
> Ben
>
>
>
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the AusNOG
mailing list