Tag Info

New answers tagged

1

I believe notify-delay is the closest thing to what you're looking for. From the reference manual: notify-delay The delay, in seconds, between sending sets of notify messages for a zone. The default is five (5) seconds. The overall rate that NOTIFY messages are sent for all zones is controlled by serial-query-rate. If you really need ...


2

This isn't really about BIND. It's about DNS in general. You're breaking a few basic rules of DNS administration. Multiple Nameservers: You should have at least two NS records defined in your zone for redundancy. Right now you don't. Both servers should be located in physically separate locations in order to prevent DNS outages. One or more of your ...


0

Multi master in BIND does not work. A slave should be installed on 172.16.32.10 instead of a master. When I started to setup a master-slave in BIND I read this documentation. Master options { listen-on port 53 { 127.0.0.1; 192.168.0.200; }; # Here we need to add our Master DNS Server IP. listen-on-v6 port 53 { ::1; }; directory ...


0

Well, the problem was very simple. My sites are hosted at Digital Ocean and I had only non-www domains in their DNS records. I still don't know how to dynamically add all subdomains (asterisk is not supported) but that's another story.


0

I believe configuring a DNS suffix via Windows TCP/IP configuration could be your solution here, providing you're running Windows PC's. This allows you to append the end of a DNS query. Appending DNS Suffix Applying via GPO Another solution is to redirect specific queries using forward look up zones within DNS management on the server, that's if there's ...


4

In a nutshell: Forwarding: just passes the DNS query to another DNS server (e.g. your ISP's). Home routers use forwarding to pass DNS queries from your home network's clients to your ISP's DNS servers. For example, for foo.example.com, a forwarding DNS server would first check its cache (did it already ask this question before), and if the answer is not in ...


0

Your nameserver cannot be queried from the internet. The glue is present, but that doesn't help if replies cannot be received by your nameserver. Here's the tail end of a +trace output similar to lVlint67's, but with the +additional flag set: loool.ro. 86400 IN NS ns1.loool.ro. ns1.loool.ro. 86400 IN A ...


0

You'll have to trace the DNS query one at a time to see where it bombs out. On your PC, try this: nslookup > set type=ns > site.com That should return a list of name servers. Pick one by going: > server ip_address_of_one_of_the_NS_servers_returned_above Then that server should have the www record in it. Confirm this by running: > set type=a ...


0

It looks like you are lacking the appropriate glue records at your registrar. $ dig +trace loool.ro ; <<>> DiG 9.9.5 <<>> +trace loool.ro ;; global options: +cmd . 929 IN NS j.root-servers.net. . 929 IN NS m.root-servers.net. . 929 IN ...


0

Ok. I wonder also whether they are rejecting it because you are giving an invalid email address for the hostmaster (root.localhost instead of a deliverable email address). I'm assuming you have also tested with dig/nslookup directly against this test nameserver from a remote location to make sure that there is no intervening firewalls, and it is properly ...


1

Your zone has a SOA of ., which your registrar may not be comfortable with. As a general rule, it's a bad idea to try to hijack . and there is no guarantee that your registrar's software will allow you to claim zone SOA that you don't actually operate. I recommend creating a single zone file and define a new zone stanza every time you need to register a new ...


11

If you are running a public accessible DNS server then other clients may be start using you. Maybe to use you as a public resolver or maybe to abuse your service for an DNS amplification attack. If you are not running a public server and have 127.0.0.1 setup as your resolver on that server: It's most likely queries your applications make to resolve ...


1

This should be a process problem. Normally admins would add new records into the zone files of both views. Force them to use scripts if their memory is bad. Discipline them if they refuse to use the scripts. But if it's a madhouse and you just need this to work, I think you might be able to do this with view based response policies. Let's say you have ...


4

yes you can do this with bind views: http://www.zytrax.com/books/dns/ch7/view.html basically, you define each view as a subnet, and then each view maintains its own zone file. depending on the source ip/subnet of the dns query, you will get a different "view". this is common for name servers to use in an "internal"/"external" views, so as dns ...


5

You have a problem with your serial number. In your live DNS zone the serial number is 2014122502. But in your new zone it is 3. Serial numbers can only be incremented; a serial number lower than the previous one will be ignored, along with all the records in the zone. Whenever you change one or more records in the zone, always change the serial number to ...


0

I solved it. Because /etc/default/bind9 had this in it: RESOLVCONF=yes A file lo.named was created in /run/resolvconf/interface with this in it: nameserver 127.0.0.1 That was then added to /etc/resolv.conf by resolvconf -u That begs the question, why would someone want to use their own server as authoritative nameserver? When a domain has a ...


4

Back in 1997, that would have been one correct SOA record interpretation of several. :) Things were a little more ambiguous back then. RFC 2308 reclassified the last field of the SOA record as the negative caching interval, otherwise known as the NCACHE field. RFC2308 §4 is the most applicable here. It not only redefines this as the NCACHE field, but also ...


1

Almost. The soa record itself has a TTL of 86400 seconds, and depending on the server-side software that will be the default ttl for that zone. Individual records within that zone - such as PTR or NS - can have their TTL overridden. I believe that a recursive query for any individual DNS record will return with its own TTL, though I say that based on ...


1

The statistics of rndc stats are from the start of the named process until now. Running rndc stats does not reset them, they will just continue counting up. If you want to find out the monthly queries, you'll need to run rndc stats every 4 weeks and calculate the monthly number yourself.


0

I had the same problem. And solved it by updating to the bind contained in Debian jessie (1:9.9.5.dfsg-7) and put the following in dnssec-validation auto; in /etc/bind/named.conf.options. Now the ad flag is set for all but the authoritative domains.



Top 50 recent answers are included