Host command successful but DNS won't resolve

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
0
down vote

favorite












I'm trying to complete the setup of my Bind9 DNS server.



Both Systems are running Debian Stretch. The serving machine (192.168.0.113) is a VM host and the client machine (192.168.0.104) is its virtual guest.



The server seems to be running without complaint, but I'm getting some confusing results. The host command resolves as I'd hoped:



$ host wiles.local
wiles.local has address 192.168.0.113


However I'm unable to reference the system by hostname anywhere else:



$ ssh wiles.local
ssh: Could not resolve hostname wiles.local: Name or service not known


Of course, I can ssh into the system by referencing the IP explicitly without issue.



The client machine does seem to be looking in the right place for its DNS:



$ nslookup google.com
Server: 192.168.0.113
Address: 192.168.0.113#53

Non-authoritative answer:
Name: google.com
Address: 216.58.192.206


I'm hoping someone can help me figure out what the distinction here is and what I can do to fix the issue.



I'll give what relevant config information I know:



On the serving system:



/etc/bind/named.conf.local



zone "wiles.local" 
type master;
file "/etc/bind/db.wiles.local";
;


/etc/bind/db.wiles.local



$TTL 86400
@ IN SOA wiles.local. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
IN A 192.168.0.113
@ IN NS localhost.
www IN A 192.168.0.104


On the connecting system:



/etc/network/interfaces



auto lo enp0s3
iface lo inet loopback

iface enp0s3 inet static
address 192.168.0.104
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 192.168.0.113


And finally:



/etc/resolv.conf



# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.113


A note on the last file: I had to disobey the loud warnings and write that line in by hand. Until having done that, this system would not resolve host names for ANY service, external or internal. I believe this to be a separate issue, that was fixed by installing and running resolvconf, but I mention it just in case the problems are related.







share|improve this question
















  • 2




    Please don't use .local as your own private TLD. It is reserved for Multicast DNS.
    – Johan Myréen
    Apr 10 at 5:01






  • 1




    Check grep ^hosts: /etc/nsswitch.conf and see askubuntu.com/questions/843943/… Note host nslookup dig use DNS directly and do NOT use nsslib like normal programs so you cannot rely on them to give the same results.
    – dave_thompson_085
    Apr 10 at 8:27











  • Check this out
    – kemotep
    Apr 10 at 13:28










  • @dave_thompson_085 I get the following output: files mdns4_minimal [NOTFOUND=return] dns myhostname This "myhostname" tag looks like it should be replaced with something else.
    – Nathan Wiles
    Apr 10 at 21:47










  • @JohanMyréen changing from TLD .local to .com did the trick, thanks! Please post this as the answer.
    – Nathan Wiles
    Apr 10 at 21:55














up vote
0
down vote

favorite












I'm trying to complete the setup of my Bind9 DNS server.



Both Systems are running Debian Stretch. The serving machine (192.168.0.113) is a VM host and the client machine (192.168.0.104) is its virtual guest.



The server seems to be running without complaint, but I'm getting some confusing results. The host command resolves as I'd hoped:



$ host wiles.local
wiles.local has address 192.168.0.113


However I'm unable to reference the system by hostname anywhere else:



$ ssh wiles.local
ssh: Could not resolve hostname wiles.local: Name or service not known


Of course, I can ssh into the system by referencing the IP explicitly without issue.



The client machine does seem to be looking in the right place for its DNS:



$ nslookup google.com
Server: 192.168.0.113
Address: 192.168.0.113#53

Non-authoritative answer:
Name: google.com
Address: 216.58.192.206


I'm hoping someone can help me figure out what the distinction here is and what I can do to fix the issue.



I'll give what relevant config information I know:



On the serving system:



/etc/bind/named.conf.local



zone "wiles.local" 
type master;
file "/etc/bind/db.wiles.local";
;


/etc/bind/db.wiles.local



$TTL 86400
@ IN SOA wiles.local. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
IN A 192.168.0.113
@ IN NS localhost.
www IN A 192.168.0.104


On the connecting system:



/etc/network/interfaces



auto lo enp0s3
iface lo inet loopback

iface enp0s3 inet static
address 192.168.0.104
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 192.168.0.113


And finally:



/etc/resolv.conf



# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.113


A note on the last file: I had to disobey the loud warnings and write that line in by hand. Until having done that, this system would not resolve host names for ANY service, external or internal. I believe this to be a separate issue, that was fixed by installing and running resolvconf, but I mention it just in case the problems are related.







share|improve this question
















  • 2




    Please don't use .local as your own private TLD. It is reserved for Multicast DNS.
    – Johan Myréen
    Apr 10 at 5:01






  • 1




    Check grep ^hosts: /etc/nsswitch.conf and see askubuntu.com/questions/843943/… Note host nslookup dig use DNS directly and do NOT use nsslib like normal programs so you cannot rely on them to give the same results.
    – dave_thompson_085
    Apr 10 at 8:27











  • Check this out
    – kemotep
    Apr 10 at 13:28










  • @dave_thompson_085 I get the following output: files mdns4_minimal [NOTFOUND=return] dns myhostname This "myhostname" tag looks like it should be replaced with something else.
    – Nathan Wiles
    Apr 10 at 21:47










  • @JohanMyréen changing from TLD .local to .com did the trick, thanks! Please post this as the answer.
    – Nathan Wiles
    Apr 10 at 21:55












up vote
0
down vote

favorite









up vote
0
down vote

favorite











I'm trying to complete the setup of my Bind9 DNS server.



Both Systems are running Debian Stretch. The serving machine (192.168.0.113) is a VM host and the client machine (192.168.0.104) is its virtual guest.



The server seems to be running without complaint, but I'm getting some confusing results. The host command resolves as I'd hoped:



$ host wiles.local
wiles.local has address 192.168.0.113


However I'm unable to reference the system by hostname anywhere else:



$ ssh wiles.local
ssh: Could not resolve hostname wiles.local: Name or service not known


Of course, I can ssh into the system by referencing the IP explicitly without issue.



The client machine does seem to be looking in the right place for its DNS:



$ nslookup google.com
Server: 192.168.0.113
Address: 192.168.0.113#53

Non-authoritative answer:
Name: google.com
Address: 216.58.192.206


I'm hoping someone can help me figure out what the distinction here is and what I can do to fix the issue.



I'll give what relevant config information I know:



On the serving system:



/etc/bind/named.conf.local



zone "wiles.local" 
type master;
file "/etc/bind/db.wiles.local";
;


/etc/bind/db.wiles.local



$TTL 86400
@ IN SOA wiles.local. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
IN A 192.168.0.113
@ IN NS localhost.
www IN A 192.168.0.104


On the connecting system:



/etc/network/interfaces



auto lo enp0s3
iface lo inet loopback

iface enp0s3 inet static
address 192.168.0.104
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 192.168.0.113


And finally:



/etc/resolv.conf



# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.113


A note on the last file: I had to disobey the loud warnings and write that line in by hand. Until having done that, this system would not resolve host names for ANY service, external or internal. I believe this to be a separate issue, that was fixed by installing and running resolvconf, but I mention it just in case the problems are related.







share|improve this question












I'm trying to complete the setup of my Bind9 DNS server.



Both Systems are running Debian Stretch. The serving machine (192.168.0.113) is a VM host and the client machine (192.168.0.104) is its virtual guest.



The server seems to be running without complaint, but I'm getting some confusing results. The host command resolves as I'd hoped:



$ host wiles.local
wiles.local has address 192.168.0.113


However I'm unable to reference the system by hostname anywhere else:



$ ssh wiles.local
ssh: Could not resolve hostname wiles.local: Name or service not known


Of course, I can ssh into the system by referencing the IP explicitly without issue.



The client machine does seem to be looking in the right place for its DNS:



$ nslookup google.com
Server: 192.168.0.113
Address: 192.168.0.113#53

Non-authoritative answer:
Name: google.com
Address: 216.58.192.206


I'm hoping someone can help me figure out what the distinction here is and what I can do to fix the issue.



I'll give what relevant config information I know:



On the serving system:



/etc/bind/named.conf.local



zone "wiles.local" 
type master;
file "/etc/bind/db.wiles.local";
;


/etc/bind/db.wiles.local



$TTL 86400
@ IN SOA wiles.local. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
IN A 192.168.0.113
@ IN NS localhost.
www IN A 192.168.0.104


On the connecting system:



/etc/network/interfaces



auto lo enp0s3
iface lo inet loopback

iface enp0s3 inet static
address 192.168.0.104
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 192.168.0.113


And finally:



/etc/resolv.conf



# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.0.113


A note on the last file: I had to disobey the loud warnings and write that line in by hand. Until having done that, this system would not resolve host names for ANY service, external or internal. I believe this to be a separate issue, that was fixed by installing and running resolvconf, but I mention it just in case the problems are related.









share|improve this question











share|improve this question




share|improve this question










asked Apr 10 at 4:35









Nathan Wiles

34




34







  • 2




    Please don't use .local as your own private TLD. It is reserved for Multicast DNS.
    – Johan Myréen
    Apr 10 at 5:01






  • 1




    Check grep ^hosts: /etc/nsswitch.conf and see askubuntu.com/questions/843943/… Note host nslookup dig use DNS directly and do NOT use nsslib like normal programs so you cannot rely on them to give the same results.
    – dave_thompson_085
    Apr 10 at 8:27











  • Check this out
    – kemotep
    Apr 10 at 13:28










  • @dave_thompson_085 I get the following output: files mdns4_minimal [NOTFOUND=return] dns myhostname This "myhostname" tag looks like it should be replaced with something else.
    – Nathan Wiles
    Apr 10 at 21:47










  • @JohanMyréen changing from TLD .local to .com did the trick, thanks! Please post this as the answer.
    – Nathan Wiles
    Apr 10 at 21:55












  • 2




    Please don't use .local as your own private TLD. It is reserved for Multicast DNS.
    – Johan Myréen
    Apr 10 at 5:01






  • 1




    Check grep ^hosts: /etc/nsswitch.conf and see askubuntu.com/questions/843943/… Note host nslookup dig use DNS directly and do NOT use nsslib like normal programs so you cannot rely on them to give the same results.
    – dave_thompson_085
    Apr 10 at 8:27











  • Check this out
    – kemotep
    Apr 10 at 13:28










  • @dave_thompson_085 I get the following output: files mdns4_minimal [NOTFOUND=return] dns myhostname This "myhostname" tag looks like it should be replaced with something else.
    – Nathan Wiles
    Apr 10 at 21:47










  • @JohanMyréen changing from TLD .local to .com did the trick, thanks! Please post this as the answer.
    – Nathan Wiles
    Apr 10 at 21:55







2




2




Please don't use .local as your own private TLD. It is reserved for Multicast DNS.
– Johan Myréen
Apr 10 at 5:01




Please don't use .local as your own private TLD. It is reserved for Multicast DNS.
– Johan Myréen
Apr 10 at 5:01




1




1




Check grep ^hosts: /etc/nsswitch.conf and see askubuntu.com/questions/843943/… Note host nslookup dig use DNS directly and do NOT use nsslib like normal programs so you cannot rely on them to give the same results.
– dave_thompson_085
Apr 10 at 8:27





Check grep ^hosts: /etc/nsswitch.conf and see askubuntu.com/questions/843943/… Note host nslookup dig use DNS directly and do NOT use nsslib like normal programs so you cannot rely on them to give the same results.
– dave_thompson_085
Apr 10 at 8:27













Check this out
– kemotep
Apr 10 at 13:28




Check this out
– kemotep
Apr 10 at 13:28












@dave_thompson_085 I get the following output: files mdns4_minimal [NOTFOUND=return] dns myhostname This "myhostname" tag looks like it should be replaced with something else.
– Nathan Wiles
Apr 10 at 21:47




@dave_thompson_085 I get the following output: files mdns4_minimal [NOTFOUND=return] dns myhostname This "myhostname" tag looks like it should be replaced with something else.
– Nathan Wiles
Apr 10 at 21:47












@JohanMyréen changing from TLD .local to .com did the trick, thanks! Please post this as the answer.
– Nathan Wiles
Apr 10 at 21:55




@JohanMyréen changing from TLD .local to .com did the trick, thanks! Please post this as the answer.
– Nathan Wiles
Apr 10 at 21:55










1 Answer
1






active

oldest

votes

















up vote
0
down vote



accepted










As pointed out in the comments by Johan Myréen, my issue appeared to be caused by the use of a reserved TLD. Since I'm not making use of mDNS, switching from .local to .com allowed my name resolutions to work properly.






share|improve this answer




















  • that may cause unknown issues down the road as well. I use .homenet ...
    – ivanivan
    Apr 16 at 1:36










  • I've reserved the domain from a registrar. That should make sure I don't run into any issues going forward as long as I still own it, right?
    – Nathan Wiles
    Apr 16 at 1:38










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);








 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f436676%2fhost-command-successful-but-dns-wont-resolve%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
0
down vote



accepted










As pointed out in the comments by Johan Myréen, my issue appeared to be caused by the use of a reserved TLD. Since I'm not making use of mDNS, switching from .local to .com allowed my name resolutions to work properly.






share|improve this answer




















  • that may cause unknown issues down the road as well. I use .homenet ...
    – ivanivan
    Apr 16 at 1:36










  • I've reserved the domain from a registrar. That should make sure I don't run into any issues going forward as long as I still own it, right?
    – Nathan Wiles
    Apr 16 at 1:38














up vote
0
down vote



accepted










As pointed out in the comments by Johan Myréen, my issue appeared to be caused by the use of a reserved TLD. Since I'm not making use of mDNS, switching from .local to .com allowed my name resolutions to work properly.






share|improve this answer




















  • that may cause unknown issues down the road as well. I use .homenet ...
    – ivanivan
    Apr 16 at 1:36










  • I've reserved the domain from a registrar. That should make sure I don't run into any issues going forward as long as I still own it, right?
    – Nathan Wiles
    Apr 16 at 1:38












up vote
0
down vote



accepted







up vote
0
down vote



accepted






As pointed out in the comments by Johan Myréen, my issue appeared to be caused by the use of a reserved TLD. Since I'm not making use of mDNS, switching from .local to .com allowed my name resolutions to work properly.






share|improve this answer












As pointed out in the comments by Johan Myréen, my issue appeared to be caused by the use of a reserved TLD. Since I'm not making use of mDNS, switching from .local to .com allowed my name resolutions to work properly.







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 16 at 1:20









Nathan Wiles

34




34











  • that may cause unknown issues down the road as well. I use .homenet ...
    – ivanivan
    Apr 16 at 1:36










  • I've reserved the domain from a registrar. That should make sure I don't run into any issues going forward as long as I still own it, right?
    – Nathan Wiles
    Apr 16 at 1:38
















  • that may cause unknown issues down the road as well. I use .homenet ...
    – ivanivan
    Apr 16 at 1:36










  • I've reserved the domain from a registrar. That should make sure I don't run into any issues going forward as long as I still own it, right?
    – Nathan Wiles
    Apr 16 at 1:38















that may cause unknown issues down the road as well. I use .homenet ...
– ivanivan
Apr 16 at 1:36




that may cause unknown issues down the road as well. I use .homenet ...
– ivanivan
Apr 16 at 1:36












I've reserved the domain from a registrar. That should make sure I don't run into any issues going forward as long as I still own it, right?
– Nathan Wiles
Apr 16 at 1:38




I've reserved the domain from a registrar. That should make sure I don't run into any issues going forward as long as I still own it, right?
– Nathan Wiles
Apr 16 at 1:38












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f436676%2fhost-command-successful-but-dns-wont-resolve%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?