Tag Info

New answers tagged

1

It seems clear that the (a) basic issue named's inability to write to its pid file. Possibilities that come to mind are conflicting entries for named user in passwd file selinux Suggestions for how you might test these theories in comments. Since changing the location of the pid file in named.conf has fixed things it still seems likely that there's an ...


2

Strategies for seeing why named fails to start: Check named-checkconf -zj output. (named-checkconf as well as named-checkzone should probably be part of your regular workflow, not only for troubleshooting) Check the logs. (named logs to syslog by default, see your named.conf for any logging configuration you have have that may override this) If none of the ...


2

The actual file not found errors come across as fairly self-explanatory (no such files exist, I suppose?). However, DS records live in the parent zone, alternatively DLV records live at the DLV server. This means that your step 4 does not exist (as per the guide you linked). Can you really not get the DS records into the parent zone instead? DLV was ...


0

Within named.conf, one can specify check-names ignore for the zone. Presumably in-addr.arpa zones default to fail whereas forward-lookup zones do not.


0

In order for you to be able to use your own BIND server you would need to setup your bind server and then change the nameserver in the domain to your bind server. This way all lookups for your domain will be obtained (by a client, or dns server) from your BIND server. In this case your best option is to redefine all dns entries in your bind configuration. ...


3

Despite what I configure or do. I get always the same result with dig (like if the data comes from other place bit not my zone file): In your output I notice you have 2 dns servers. ;; AUTHORITY SECTION: mydomain.com. 63046 IN NS dns1.kontent.com. mydomain.com. 63046 IN NS dns2.kontent.com. Your domain server is ...


0

I think you may need to add a . to the end of mydomain.com on the MX lines as below * IN A WW.XX.YY.ZZ mydomain.com. IN MX 1 ASPMX.L.GOOGLE.COM. mydomain.com. IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. mydomain.com. IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. mydomain.com. IN MX 10 ALT3.ASPMX.L.GOOGLE.COM. mydomain.com. IN MX 10 ...


1

The two A-records seem to be correct. That's the way to do rounud-robin. Have you increased the SOA serial number, reloaded the zone and has it propagated to the slave? For testing it's best to avoid any intermediate nameservers and query the primary NS directly: dig a mydomain.ch. @ns1.mydns.ch. That will talk directly to your nameserver. If you use ...


0

Your server is already behaving exactly as you want, but you're querying it not from localhost. Use 127.0.0.1 or localhost for the name server you query. If you used localhost it would say localhost, not slcdns1.redacted.com in the output. Also, when asking DNS questions, it's mind-numbingly frustrating when the questioner tries to mask the domains and / or ...


0

If this is supposed to be an authoritative server, there are a few things you may want to change. allow-query { localhost; 175.75.517.715; }; This line says allow queries from only those two addresses. recursion no; This may be a good thing, unless you're an ISP, or running a DNS server for your own network.


-2


6

One aspect of this is that recommending "anti-virus" to be on everything is a safe bet, for the auditor. Security audits aren't entirely about actual technical safety. Often they are also about limiting liability in case of a lawsuit. Let's say your company was hacked and a class action lawsuit was filed against you. Your specific liability can be ...


1

You are clearly reinventing the wheel, only that your wheel is square form. DNS servers have a "view" concept for this. You define multiple view for multiple client subsets. And each view holds and gives unique addresss-space representation to each clients subset. You should read about view and match-clients statements. And what's more important, this way ...


1

There are two main kinds of DNS servers: authoritative and recursive. An authoritative DNS server tells the world what IP addresses should be used for each hostname within a domain. Lately it's become possible to associate other data with a name, such as e-mail filtering policies (SPF) and cryptographic certificates (DANE). A resolver, or recursive DNS ...


1

If this is for SOX compliance, they're telling you to install antivirus, most likely, because somewhere you have a policy that says all servers must have antivirus installed. And this one doesn't. Either write an exception to the policy for this server, or install AV.


2

You would build a different rndc.conf file for each instance of named you're running that contains the proper ip:port combination. You can then use the -c flag with rndc to read the desired config file. From the rndc man page: -c config-file Use config-file as the configuration file instead of the default, /etc/rndc.conf.


7

DNS servers have become popular with PCI auditors this year. The important thing to recognize is that while DNS servers do not handle sensitive data, they support your environments which do. As such, auditors are starting to flag these devices as "PCI supporting", similar to NTP servers. Auditors typically apply a different set of requirements to PCI ...


2

If your DNS servers fall into PCI DSS scope, you may be forced to run AV on them (even though it's downright silly in most cases). We use ClamAV.


3

You didn't define a category in that snippet. category queries { query_log; }; All the channel query_log statement does is define a logging target named query_log. If it is present in logging_category_remote.conf, please share the contents of that file.


10

Typical modern anti-virus software does more accurately attempt to find malware and is not only limited to viruses. Depending on the actual implementation of a server (dedicated box for a dedicated service, container on a shared box, additional service on "the only server"), it's probably not a bad idea to have something like ClamAV or LMD (Linux Malware ...


2

This could've been a knee-jerk reaction to the shellshock bash vuln, it was suggested online that bind could be affected. EDIT: Not sure it was ever proven or confirmed.


17

The first thing you need to understand about auditors is they may not know anything about how the technology in scope is used in the real world. There are a lot of DNS security vulnerabilities and issues that should be addressed in an audit. They will never get to the real issues if they are distracted by bright shiny objects like "antivirus on a DNS ...


28

Sometimes auditors are idiots... This is uncommon request, though. I would counter the auditors recommendation by securing/limiting access to servers, adding an IDS or file-integrity monitoring or bolstering security elsewhere in your environment. Antivirus doesn't have any benefit here. Edit: As noted in the comments below, I was involved in the launch ...


1

Unless the resolver server used by these clients implements the draft spec for Client Subnet in DNS Requests, which embeds the client address information in the query dns message, there is no way to know the address of the original client at any point after that. However, even if you do have a server that implements the draft specification for this, the ...


1

Another important detail I just learned today thanks to a coworker: Ensure ONLY your DNS server is in resolv.conf. I added 127.0.0.1 to my list instead of replacing my hosts default DNS servers (expecting it to hit mine first and fallback to the others), and found out I was round-robin on the DNS servers, so 2/3rd of my queries went out over the other ...


4

DNS has proper built in replication, so why bother with something like that? You're introducing an unnecessary a single point of failure. Especially when you'll still need to issue a reload of any updated zone files on both DNS servers, as simply updating the zone file does not make it active on either of the servers.


2

Based on the presented dig +trace output, the most likely cause is that the packets hitting the internet facing IPs are not being received by the server process that you think they are. This can be definitively proved with the following CHAOS query, which demonstrates that the internet facing IP is being managed by a PowerDNS daemon. $ dig @95.142.155.4 ...


2

The examples above, at least at the the time of this writing, are showing contradictory results. I assume you are changing host names and IP addresses to protect your identity? That is all fine, but makes it muy difficult to diagnose the problem. So, here is what I propose. Start by making sure your DNS records are set correctly. Verify your domain name ...


0

This will manipulate the zone file in such a way that it will add the correct serial number and append the right nameserver. You need to call the script for every zone file. You can use find or a shell loop of a glob to do this. This relies on the format of the serial number being such that it contains "; Serial Number" on the line. It also expects the ...


1

The order of resource records in a zone file is mostly arbitrary, simply append the new records at the end. Don't forget to update the serial number though!


1

I had this problem and resolved it by simply restarting spamd. Apparently it needed a reboot to update the name server it was connecting to. Also ensure you've told your system to use your new local nameserver by configuring /etc/resolve.conf with: nameserver 127.0.0.1 And in case it's helpful, here's my /etc/named.conf file: http://pastebin.com/r0RYawGj ...


0

Just in case it wasn't clear by the OP's comment below MadHatter's respond, "problem was dnssec", I'm posting this answer explicitly since I too found it solved my problem. I've setup a caching, forwarding-only BIND server and it wasn't forwarding. The queries were going to the root server with a several-second-delay. Disabling the dnssec options fix this, ...



Top 50 recent answers are included