Re: how to setup a local root nameserver?
see my comments below ...
On Tue, Feb 2, 2010 at 8:18 AM, Joseph S D Yao j...@tux.org wrote:
On Tue, Feb 02, 2010 at 12:50:56AM +0100, fddi wrote:
Hello,
I need to setup a local named configuration so that ANY request will be
resolved
to a specific single IP only.
I mean any kind of DNS resolutin request
www.luth.se
www.isc.org
www.anything.tld
should be resolved in 172.16.30.30 for example
zone . {
type master;
file zone.root;
};
zone.root:
@ SOA ...
NS localhost
localhost A 127.0.0.1
* A 172.16.30.30
NOTE: this does exactly what you asked. And may have unexpected
consequences [as in, be careful what you ask for; you may get it]. For
instance, this had better be the name server, as well! NO OTHER IP
ADDRESS IN THE ENTIRE WORLD will be resolved.
Unless you add domains on this same name server.
Correct .. but as you say you just add domains on the same name server.
Simple make the NS the localhost and assign localhost the A record of
127.0.0.1. Or lets say the name server is at 172.16.30.31 then you can do as
follows
NS any.domain.name
any.domain.name A 172.16.30.31
* A 172.16.30.30
That will work too.
regards
joe baptista
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Having multiple name servers - is it really necessary
Hi, We have two registered name servers to answer internet queries. One is on site and the other is a service of our ISP. The problem is that every once in a while the secondary server doesn¹t successfully complete zone transfers and the data expires. I¹m not sure what technically how the server answers when queried for addresses it no longer thinks are valid, but even after it¹s fixed it takes a while for the bad data to go away. What I¹m wondering is, what are the consequences of simply not using the secondary server. Right now we are looking at hardened appliances configured into a high availability cluster and I figure the pipe to the outside has a high likelihood of going down then does the cluster. So, if name servers out in the internet can¹t even reach our server because our connection is down, is that something that also propagates and get¹s cached (i.e. Is no data treated the same as bad data by upstream bind servers? Thanks, Rob Rob Tanner UNIX Services Manager Linfield College, McMinnville Oregon ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Having multiple name servers - is it really necessary
On February 2, 2010 2:25:50 PM -0800 Rob Tanner rtan...@linfield.edu wrote: cached (i.e. Is no data treated the same as bad data by upstream bind servers? I didn't entirely follow your ramble (paragraphs would have helped), but it's not BIND or other nameservers that would be the real problem, it's the applications that depend on name services. For example, if your link goes down and instead of a DNS lookup which results in an answer of an MX server that doesn't respond, someone trying to send you mail would (after cache timeout) get back a non-result DNS answer and might bounce a mail instead of queueing it for later delivery. That's perhaps not a good example because actually MTAs should handle this case as a transient error and queue any mail, but you get my point. Consider also that folks just browsing your website will get a different kind of error which might lead them to believe that your site doesn't even exist. That would definitely be worse than connection timed out. Other applications may result in similar types of disconcerting errors instead of just connection timeouts. You really do need multiple nameservers, and you absolutely need to make your DNS zone transfers reliable. I do sympathize with you. Old data is often worse than no data. -frank ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Having multiple name servers - is it really necessary
On 2/2/2010 5:25 PM, Rob Tanner wrote: Hi, We have two registered name servers to answer internet queries. One is on site and the other is a service of our ISP. The problem is that every once in a while the secondary server doesn't successfully complete zone transfers and the data expires. As the domain owner, you can set the expiration interval in the SOA record. Sounds like you set the interval way too short. Expiration intervals of a month or more are common. You need to give yourself enough time to detect that replication is broken, and fix it. As for detecting whether replication is broken or not, you could implement either a) scanning your logs to ensure that refresh queries and/or zone transfers are occurring, or b) probing the secondary/secondaries to see if their version of the zone is up to date (look at the serial number in the SOA), c) both of the above These measures may require that you force updates on a regular basis, which you can do by making some sort of dummy change, if no real changes have been made recently. I'm not sure what technically how the server answers when queried for addresses it no longer thinks are valid, but even after it's fixed it takes a while for the bad data to go away. If the zone truly *expires* then a nameserver will typically give a SERVFAIL response for any query of a name in the zone. Since SERVFAIL usually isn't cached very long, I'm assuming that by bad data you mean the staleness of the data leading up to the eventual expiration of the zone. Once replication connectivity has been restored, then a refresh would be forced on the slave, and it would have a current version of the zone (how you do that depends on what DNS implementation you're using, in extreme cases it might be necessary to delete a file, or completely drop and re-add the slave-zone definition in the config). As for stale records cached in non-authoritative servers, you as the domain owner control the persistence of those through your TTL settings on the individual records, and the negative-TTL setting in the SOA record for the zone. What I'm wondering is, what are the consequences of simply not using the secondary server. Right now we are looking at hardened appliances configured into a high availability cluster and I figure the pipe to the outside has a high likelihood of going down then does the cluster. So, if name servers out in the internet can't even reach our server because our connection is down, is that something that also propagates and get's cached (i.e. Is no data treated the same as bad data by upstream bind servers? Well, the Internet standards explicitly require at least 2 nameservers, and if the zone/zones is/are delegated directly from a registry, usually they enforce that rule. It would not be advisable to only have 1 delegated nameserver. Many apps distinguish between host not found and cannot connect errors. In the case of a store-and-forward subsystem like SMTP mail, for instance, the former is fatal while the latter will be retried for some period of time. Also, more generally, putting all your eggs in one basket -- if this fails then this other thing probably won't work either -- rarely forms the basis of a responsible disaster recovery plan. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to setup a local root nameserver?
On Tue, Feb 02, 2010 at 05:05:12PM +0100, fddi wrote: thank you for the precious suggestion I just missed the * hint :) so my configuration was almost done. here is the final configuration and it works... thanks to all I'm amazed that this works. Oh, I see why - it thinks that the IP address is a domain NAME! You MUST have a name to the right of your NS record. But in this case, you have the host name 172 in the subdomain 16.30.30. Normally, to make this work, you must add 172.16.30.30. IN A172.16.30.30 and have a separate zone for the domain 16.30.30. [which is QUITE DIFFERENT from the domain 30.30.16.in-addr.arpa.]. If you don't understand this, think about it for a while - and about the fact that what is to the right of the NS record is NEVER interpreted as an IP address, it is ALWAYS interpreted as a name. Thank you for the amusing anecdote. ;-) $TTL86400 $ORIGIN . @ 1D IN SOA @ root ( 42 ; serial (d. adams) 3H ; refresh 15M ; retry 1W ; expiry 1D ); minimum 1D IN NS172.16.30.30 * IN A172.16.30.30 -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to setup a local root nameserver?
On Tue, Feb 02, 2010 at 10:03:32AM -0500, Joe Baptista wrote: ... instance, this had better be the name server, as well! NO OTHER IP ... You know, when I wrote this I was thinking of the recommended separate resolving name server from authoritative name server. But in the case our friend from Italy was describing, usually they are the same. If the resolving name server to which all the workstations or kiosks are pointing has a different IP address from the uiniversal IP address, it really doesn't matter! ;-) -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
