Tag Info

Hot answers tagged

2

Yes. RFC 1033 states: "NS records for a domain exist in both the zone that delegates the domain, and in the domain itself" and therefore NS records can not be omitted completely. Glue records are only needed when the name-servers are within the same zone as the domain. By registering all your domains on the same name-servers you already reduce the effort ...


1

It is perfectly alright to have a domain name/zone-file pointing to name-servers outside of that domain i.e. it is perfectly alright to use ns1.example.com as the name-server for the example.org domain. Not only means that you don't need Glue records in the example.org zone, it is often easier to administer as well. I think you made a slight conceptual ...


1

It's not clear where do you run the ping. But your assumption that client tries to get the ip of the server from the master dns server is plain wrong. DNS client contacts the servers of /etc/resolv.conf and only these servers. The server makes a choice to respond in only one of these ways: if it is a master for the domain, it responds based on it's ...


1

Not in the configuration you're talking about - at least, not in a way that would make any kind of sense to implement. To have two different resources in different locations behind the same IP, you need to use BGP anycast (which you can't do in AWS/Rackspace). Failing that, you'd need to have something behind that IP address that's proxying to ...


1

The SOA record is at yoda.ex-mailer.com ($ORIGIN yoda.ex-mailer.com. redefines the origin to that). However, the rest of the zone file seems to contain nyctelecomm.com. records. Also, you specify the initial origin to dnssec-signzone as nyctelecomm.com. This seems to be a mismatch which will lead to this kind of error. (The SOA and NS records are supposed ...


1

It's important to understand that each query will hit exactly one view and that is the first view matching the incoming query (based on match-*). You have three views, two of which have no requirements at all as to which queries will match. This results in a situation where depending on how the views are ordered either one or two views cannot ever be ...


1

From what I see the names of your config parts are misleading (furthermore, I can say that the Debian tradition of splitting one decent config file to over 9000 includes is misleading and counter-productive in general). Considering this: view clauses are processed in the order in which they appear in the named.conf file. Thus, in the example above the ...


1

Sort of. You can't simply put everything in '.' as in your example. Technically you could, but you would cause yourself far more issues down the road than you're trying to solve. Just don't. '.' is the root zone of all of DNS. You should already have '.' defined as a type hint zone. You need to define every zone in the config file, but you can ...


1

I found the answer right after posting the question, so I answer myself: I found out this by looking at the log when restarting the bind9 server. Reverse zones are seen by the server as <subnet.in.reverse>.in-addr.arpa, so the 10.5.0 zone (from the 10.5.0.zone file) becomes the 0.5.10.in-addr.arpa zone. So now I can just use the command on my previous ...


1

The same way you do with a forward zone, by requesting the SOA record of the zone. For IP-address A.B.C.D the zone name is often C.B.A.IN-ADDR.ARPA but you can simply request the SOA for the host D.C.B.A.IN-ADDR.ARPA: dig SOA D.C.B.A.IN-ADDR.ARPA And for your 10.5.0.x range: dig SOA 0.5.10.in-addr.arpa For the Google public DNS resolver 8.8.8.8 ...


1

bind cannot cache a record for more time than the record's TTL (time to live). www.google.com has a TTL of 5 minutes, therefore the cached record will expire after that much time.


1

Works for me for years. Both servers in a failover set are updating the master (why anyone of them should even try to update the slave ?). Master is replicating to the slave.



Only top voted, non community-wiki answers of a minimum length are eligible