# Using a local DNS server

**URL:** <https://community.letsencrypt.org/t/using-a-local-dns-server/22747>\
**Category:** Help\
**Created:** [November 16, 2016, 7:54pm UTC](https://community.letsencrypt.org/t/using-a-local-dns-server/22747 "2016-11-16T19:54:42Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![jimoe](https://avatars.discourse-cdn.com/v4/letter/j/48db29/32.png) [@jimoe](https://community.letsencrypt.org/u/jimoe)\
**Post date:** [November 16, 2016, 7:54pm UTC](https://community.letsencrypt.org/t/using-a-local-dns-server/22747/1 "2016-11-16T19:54:42Z")

</div>

Please fill out the fields below so we can help you better.

My domain is: \*.sma.com

I ran this command: ./certbot-auth

It produced this output: DNS problem: NXDOMAIN looking up A for [twc.sma.com](http://twc.sma.com)

My operating system is (include version): opensuse 42.1

My web server is (include version): apache 2.4

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don’t know): Yes

I’m using a control panel to manage my site (no, or provide the name and version of the control panel): No

We use the domain “[sma.com](http://sma.com)” for our local network. The domain unfortunately is also registered and is in use on the Internet; the domain has passed through 4 or 5 owners since we established our local network in 1998. Generally this is not an issue as our local DNS server knows what’s what.

cert-bot-auth, OTOH, apparently uses a non-local DNS server to resolve the domain names of interest, which results in the type error indicated above.

Is there a way to tell certbot-auth to use the local DNS server rather than its default one?

---

<div class="post-metadata">

**Author:** ![tialaramex](https://avatars.discourse-cdn.com/v4/letter/t/f08c70/32.png) [@tialaramex](https://community.letsencrypt.org/u/tialaramex)\
**Post date:** [November 16, 2016, 8:12pm UTC](https://community.letsencrypt.org/t/using-a-local-dns-server/22747/2 "2016-11-16T20:12:17Z")

</div>

Let’s Encrypt is a public Certificate Authority for the Web PKI. So far as Let’s Encrypt is concerned, you’re not the owners of [sma.com](http://sma.com), that’s somebody else. So you can’t be issued certificates for [sma.com](http://sma.com)

All CAs participating in the Web PKI will (or at least should) also refuse you certificates for [sma.com](http://sma.com) because you’re not the true owners. If you need certificates for names in [sma.com](http://sma.com) you will need to either operate your own CA (for which you can make whatever rules you want) or find a private CA which is willing to issue for [sma.com](http://sma.com) even though they know your [sma.com](http://sma.com) isn’t the one on the Internet. They are likely to charge a hefty fee for this, not least because they effectively rule out ever having [sma.com](http://sma.com) or any business which wants to talk to [sma.com](http://sma.com) as a customer.

---

<div class="post-metadata">

**Author:** ![jimoe](https://avatars.discourse-cdn.com/v4/letter/j/48db29/32.png) [@jimoe](https://community.letsencrypt.org/u/jimoe)\
**Post date:** [November 16, 2016, 8:16pm UTC](https://community.letsencrypt.org/t/using-a-local-dns-server/22747/3 "2016-11-16T20:16:37Z")

</div>

I see. Thanks.

(blah blah blah to get more than 20 chars)

---

<div class="post-metadata">

**Author:** ![tialaramex](https://avatars.discourse-cdn.com/v4/letter/t/f08c70/32.png) [@tialaramex](https://community.letsencrypt.org/u/tialaramex)\
**Post date:** [November 16, 2016, 8:19pm UTC](https://community.letsencrypt.org/t/using-a-local-dns-server/22747/4 "2016-11-16T20:19:45Z")

</div>

Oh also, just in case it’s not obvious, a private CA (including your own) would not be trusted by most systems out of the box like Let’s Encrypt is. The rules that let them get that trust are the same rules that don’t let them issue you certificates for names that (as far as the Internet is concerned) aren’t yours.

However, a lot of software can be configured to trust another CA. For example in Windows this can be part of a “Group Policy” configured centrally and installed in all the machines that are part of a Domain. So for your internal use a private CA can be a very practical option.

---

<div class="post-metadata">

**Author:** ![TCM](https://avatars.discourse-cdn.com/v4/letter/t/a587f6/32.png) [@TCM](https://community.letsencrypt.org/u/TCM)\
**Post date:** [November 16, 2016, 11:42pm UTC](https://community.letsencrypt.org/t/using-a-local-dns-server/22747/5 "2016-11-16T23:42:23Z")

</div>

Also, stop using (someone else’s) global domains in a local network. Best practice is to register a domain and use a subdomain locally, like [lan.example.com](http://lan.example.com).

---

<div class="post-metadata">

**Author:** ![pfg](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/pfg/32/1924_2.png) [@pfg](https://community.letsencrypt.org/u/pfg)\
**Post date:** [November 17, 2016, 12:58am UTC](https://community.letsencrypt.org/t/using-a-local-dns-server/22747/6 "2016-11-17T00:58:40Z")

</div>

This is indeed very good advice, and not just because of SSL. There are many other things that can go wrong if you use public domains that you do not own for your local network. As an example, the owner of said domain could create DNS records that Windows queries to discover proxy settings, which would essentially let them observe (and MitM) all your traffic, see [WPAD Name Collision Vulnerability](https://www.us-cert.gov/ncas/alerts/TA16-144A).

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/letsencrypt/original/3X/c/a/ca6c06ea1ea201324bba7048c6841ce60236468d.png) [@system](https://community.letsencrypt.org/u/system)\
**Post date:** [December 17, 2016, 12:58am UTC](https://community.letsencrypt.org/t/using-a-local-dns-server/22747/7 "2016-12-17T00:58:40Z")

</div>

Closed on December 17, 2016, 12:58am UTC

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
