-
#1
Shouldn’t every domain have the same soa settings in your dns zones? I have over 20 domains on my server with some being .ca, .net and some with a hyphen in the name.com. I’ve been having email issues so I thought I’d check my dns settings and found some errors.
After following some of the excellent threads in this forum, I’ve managed to get my errors down to 1 for all domains using MX tools with the exception of the .ca, .net and hyphen related domains.
Every domain has the same soa values:
43200-refresh
7200-retry
1800000-expire
43200-minimum ttl
Yet when I run an smtp test on .ca, .net or hyphen mixed domain names I keep seeing this:
SMTP Banner Check Reverse DNS does not match SMTP Banner More Info
SMTP TLS Warning — Does not support TLS. More Info
SMTP Server Disconnected May be an open relay. More Info
SMTP Reverse DNS Mismatch OK — 71.19.244.97 resolves to mydomain.com
SMTP Valid Hostname OK — Reverse DNS is a valid Hostname
Here are the Domain Health screenshots also to give you a better understanding of what I’m seeing:
.com domains
.ca,.net and hyphenated domains
Am I supposed to be setting the dns different for these domains somewhere else?
Last edited: Apr 9, 2016
-
#2
Hello
I suggest completing these SMTP tests manually as opposed to using a third-party utility to verify if you see the same results. There’s a third-party guide on using telnet to test SMTP connections at:
SMTP, testing via Telnet — Ubuntuwiki.net
In addition, you can use the «host» command to check reverse DNS entries.
Note that the «Name servers on same subnet» warning simply indicates that your name servers are on the same IP address subnet. This is not necessarily an issue, though some administrators prefer separate a separate subnet for each name server for added redundancy.
Thank you.
-
#3
Hello
I suggest completing these SMTP tests manually as opposed to using a third-party utility to verify if you see the same results. There’s a third-party guide on using telnet to test SMTP connections at:
SMTP, testing via Telnet — Ubuntuwiki.net
In addition, you can use the «host» command to check reverse DNS entries.
Note that the «Name servers on same subnet» warning simply indicates that your name servers are on the same IP address subnet. This is not necessarily an issue, though some administrators prefer separate a separate subnet for each name server for added redundancy.
Thank you.
Thanks Michael, I get a command not found error when trying to telnet alt3.gmail-smtp-in.1google.com 25 from my server. I am trying to follow google’s instructions on their form to see why they are blocking my ip from sending email to gmail.com email addresses when no other canned email services or isp’s are doing the same.
-
#4
I get a command not found error
You can install the «telnet» package with a command such as:
Thank you.
-
#5
You can install the «telnet» package with a command such as:
Thank you.
Thanks again Michael, it turned out to be exim rejecting the email as per this log:
2016-04-12 11:40:28 H=mail-yw0-f194.google.com [209.85.161.194]:35114
X=TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no F=<[email protected]>
rejected RCPT <[email protected]>: «JunkMail rejected —
mail-yw0-f194.google.com [209.85.161.194]:35114 is in an RBL, see Blocked — see
SpamCop.net — Blocking List ( bl.spamcop.net )»
I’ve been told it isn’t a good practice to install telnet onto a dedicated server. Is that true? I know google requires it to provide them with information when filling out their form.
Last edited: Apr 13, 2016
DENIC, which is the German registry for all .DE domains, has a number of strict rules for nameservers.
You can perform a nameserver check on their website via https://www.denic.de/en/service/tools/nast/. The results will show which of their rules are not met, and more information on how to meet the requirements.
Errors when changing the nameservers
When you receive an error after changing your nameservers, it is often because of misconfigured nameservers. In this case, use the Nameserver Check on DENIC’s website to check if your nameservers are configured correctly.
If your control panel shows an error, you will see at least one error message when performing the check on DENIC’s website. More information about the errors will also be shown on the same page. We will explain one of the most common errors below:
The error message «Inconsistent set of NS RRs» means that the configuration of your nameservers does not meet DENIC’s standards. Check which NS records are in your primary nameserver and compare them to what you are trying to enter in the control panel.
The NS records of your primary nameserver have to match the nameservers that you are trying to set in your control panel exactly. This information is checked by DENIC.
If they do not match, you can solve this in two ways:
- Make sure the NS records in your primary nameserver point to the nameservers you are trying to enter in the control panel.
- Or make sure you enter the nameservers that are in your primary nameservers, in your control panel.
After changing the (configuration of) your nameservers, perform the Nameserver Check again. If the check does not return any errors, you can retry changing the nameservers in your control panel.
Attention: The IP addresses of your nameservers can not be on the same subnet.
For instance: If your primary nameserver’s IP address is 1.2.3.100, then your secondary nameserver’s IP address can not be 1.2.3.101. Because the first three numbers are the same, these IP addresses are on the same subnet. In this case, change your nameservers and use an extra nameserver that is on a different subnet.
In this article we have explained what to do when you get an error message regarding the nameservers of a .DE domain.
Should you have any questions left after reading this article, do not hesitate to contact our support department. You can reach them via the ‘Contact us’ button at the bottom of this page.
If you want to discuss this article with other users, please leave a message under ‘Comments‘.
The parent zone is not obligated to provide glue records for a delegation if the delegated-to host names is not under the delegated name. Glue records are only needed if a delegation points to something that the delegation would need to be followed for to be useful.
Since you are delegating gignouser.com to name servers under eu.clouds.host, that is not the case and glue records are thus not required to be returned by the name servers hosting the delegation to gignouser.com — meaning the com TLD DNS servers.
If you look at the delegation of clouds.host you will see that the delegation from the nic.host DNS servers does include glue records.
I do however notice something that may contribute to problems:
You are serving NS RRs with a 0 TTL, for both domains. This can be problematic. If you want to minimize the time that DNS servers cache the delegation data (why you’d want to do that to such an extent I don’t know), then serve it with some small but non-zero TTL. I suggest using a minimum of 10 seconds TTL to give resolvers and proxies a chance to do their thing even if they abide by TTLs internally during the recursive resolution process.
I would fix the TTLs first, and see if the problem goes away. It’s certainly possible that the report tool you are using is being confused by the zero TTLs.
I also notice that it appears that you are running both name servers on the same subnet — specifically, on adjacent IP addresses — which presents a massive single point of failure. If that is the case, strongly consider getting an off-site slave DNS server, especially if you want to serve zone authority data with very short TTLs. While «everything else will be down anyway» is a valid point on the face of it, which error would you rather the users get if your servers are unavailable; «the host name www.gignouser.com was not found» or «the server did not respond»? I would absolutely prefer the latter, even if the end result at that moment is the same in that your web site is unavailable.
I moved from a flat networking topology to one with different VLANs, using a managed Netgear L3 switch and a VLAN unaware modem/router (Fritzbox). I’ve set up VLAN routing and shared internet access following this tutorial: https://kb.netgear.com/30818/How-to-configure-routing-VLANs-on-a-NETGEAR-managed-switch-with-shared-internet-access Opens a new window Opens a new window .
As in the above tutorial, the switch acts as a DHCP server for the different VLANs. In the DHCP server settings of the switch, the VLAN interface IP address is set as the gateway/default router address for each VLAN and the Fritbox is set as the DNS server. Routing between VLANs is working fine.
In VLAN 178 (192.168.178.0 /24, which was the only subnet I had in the flat networking topology setup), I have a Windows 2012 Essentials server (192.168.178.10) with shared folders. It acts as a DNS server (with DNS forwarding to the Fritzbox) for the domain [domainname].local . A few computers in VLAN 178 are joined to this domain and have the fixed IP of the server as their DNS server. All other computers/devices obtain their DNS settings automatically and thus get the Fritzbox as their DNS server.
From a computer e.g. in VLAN 30 (192.168.30.0 /24), I can access the server’s shared folder via \192.168.178.10[shared folder] and via \[FQDN][shared folder] but not via \[servername][shared folder]. Likewise, I can ping the server via its IP address and via its FQDN but not via its host name. A tracert to the server’s IP works (goes via 192.168.30.254 (VLAN 30 interface IP) to 192.168.178.10).
Nslookup [servername].[domainname].local from a computer in VLAN 30 gives:
Server: fritz.box
Address: 192.168.178.1
Name: [servername].[domainname].local
Address: 192.168.178.10
Nslookup of the server name gives from a computer in VLAN 30 gives:
Server: fritz.box
Address: 192.168.178.1
*** fritz.box can’t find [servername]: Non-existent domain
Is there a way to access the server’s shared folder via \[servername][shared folder] ? I assume this could be set up in the hosts file of a computer but that wouldn’t work if I wanted to access the server’s shared folder with a music player such as Sonos.
Entering the server name with its IP address in the ‘Static Entry to the Local DNS Table’ of the switch (p79 of the switch’s manual Opens a new window Opens a new window) doesn’t help.
Sorry if this is a stupid question but as I’m coming from a flat network topology with very basic knowledge of networking, the learning curve has been steep but I find it interesting and I am eager to learn 
check
Best Answer
ds53
This person is a verified professional.
Verify your account
to enable IT peers to see that you are a professional.
chipotle
Hi there,
Ok, so the issue that is occurring is that the DNS (fritz) can’t perform name resolution as ServerName has no domain name, and is therefore not an FQDN. Sorry to boil this right down, bear with me here.
When name resolution occurs, the client checks in the following order:
— Local DNS Cache (has the name already been resolved?)
— Hosts file (is it covered in the hosts file?)
— DNS (contacts DNS server to see if it can resolve it?)
— NetBIOS name resolution (can I find the name through, effectively, a broadcast in simple terms?)
When your client is on the same subnet as your server, assuming the local cache, the hosts file and DNS have not returned a result, the broadcast for ServerName can be successful. This however will not work for name resolution for client/server on different subnets.
So, what you could do is specify DHCP Option 15, DNS Suffix. Your DHCP Clients will then receive their IP Address, Subnet Mask, Gateway, and DNS Suffix.
When you specify a destination name, in this case, ServerName, the name resolution will attempt to resolve ServerName.DNSSuffix.
I’ll attached a couple of screenshots/manual details on where to set it.
You could manually set a suffix on each PC (screenshot also attached) , but that’s extra work.
Hope this helps.
The bottom line is, the fritz needs a domain name to go with the ServerName otherwise it doesn’t know where to look it up.
2 found this helpful
thumb_up
thumb_down
View Best Answer in replies below
Read these next…
Snap! — No-Password Logins, Solar Powered Water Filter, Glitch in the Matrix?
Spiceworks Originals
Your daily dose of tech news, in brief.
Welcome to the Snap!
Flashback: February 9, 1996: Introduction of the Bandai Pippin (Read more HERE.)
Bonus Flashback: February 9, 1990: Galileo Probe does a Venus Flyby (Read more HERE.)
You nee…
Roku TV being used as Wallboard Issues
Hardware
Helping someone out at their shop. They have 4 large Roku screens and 2 laptops with dual HDMI ports for video. They are viewing static website business dashboards and PowerPoint. At first all 4 screens connected to wireless, worked for a while but with a…
Charging for SSO
Security
We have SSO set up with around 5 or 6 solution providers via our M365. Not one of them charges for this, they just sent us the documentation.I identified another online service in use by one of our departments which would benefit from using SSO for staff …
Spark! Pro series — 9th February 2023
Spiceworks Originals
Today in History: America meets the Beatles on “The Ed Sullivan Show”
At approximately 8:12 p.m. Eastern time, Sunday, February 9, 1964, The Ed Sullivan Show returned from a commercial (for Anacin pain reliever), and there was Ed Sullivan standing …
Green Brand Rep Wrap-Up: January 2023
Spiceworks Originals
Source Opens a new window Opens a new windowHi, y’all — Chad here. A while back, we used to feature the top posts from our brand reps (aka “Green Gals/Guys/et. al.) in a weekly or monthly wrap-up post. I can’t specifically recall which, as that was ap…
