Re: Basic info on interfaces file
This is not really a BIND question; this mailing list is for BIND questions. RTM. Start with this command: man 5 interfaces You can use the 'q' key to exit from the manual page. The BIND name server will not read /etc/resolv.conf (which is what that dns-nameserver line refers to), so set it to '::1'. Or whatever makes sense to you. The 'address' line sets the local address for the interface, on the server itself. Good luck. The following may also be of some help: https://help.ubuntu.com/community/BIND9ServerHowto Regards, Chris On Mar 31, 2015, at 11:33 PM, STEPHEN EYRE sce...@btinternet.com wrote: For educational interest i am setting up an authoritative only DNS server at home and after a few failures i am starting at the beginning again. I am using Bind9 with Ubuntu 14.04 server software. Todays question revoles around the /etc/network/interfaces file. In the line starting with 'address' i have inserted the internal IP address of the machine running the bind software. I presume that is correct? In the line starting with 'dns-nameserver' i am unsure whether it should be the same the 'address' as above or whether it should be my static public IP address. Which should it be? Thanks for any assistance you may wish to give Stephen Eyre Sent from Yahoo Mail on Android ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Basic info on interfaces file
For educational interest i am setting up an authoritative only DNS server at home and after a few failures i am starting at the beginning again. I am using Bind9 with Ubuntu 14.04 server software. Todays question revoles around the /etc/network/interfaces file. In the line starting with 'address' i have inserted the internal IP address of the machine running the bind software. I presume that is correct? In the line starting with 'dns-nameserver' i am unsure whether it should be the same the 'address' as above or whether it should be my static public IP address. Which should it be? Thanks for any assistance you may wish to give Stephen Eyre Sent from Yahoo Mail on Android ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Basic info on interfaces file
Chris Buxton cli...@buxtonfamily.us wrote: The BIND name server will not read /etc/resolv.conf (which is what that dns-nameserver line refers to), so set it to '::1'. Or whatever makes sense to you. However! Since you are configuring BIND to be an authoritative-only server, you want the local resolver to point to some other recursive name server, not to the name server on localhost. If your network was previously configured with DHCP then you can probably get the correct IP address from the nameserver line(s) in /etc/resolv.conf or /var/run/resolvconf/resolv.conf Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Irish Sea: West 6 to gale 8, veering northwest 3 or 4 later. Moderate or rough becoming slight or moderate. Rain or showers. Moderate or good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: subdomain with domain
zone _msdcs.domain {
[..]
file data/db.192.168.1.2.slave;
};
zone domain {
[..]
file data/db.192.168.1.2.slave;
};
Both zones are being backed by the same file, so one will be overwriting
the other. This may not be the cause of the half-working situation, but
it won't be helping. Do the bind logs (not sure where Fedora puts them
though - /var/log/messages?) contain any errors?
Unless domain is really '192.168.1.2', I would suggest naming your
file after the zone that it is going to contain - e.g.
file data/db._msdcs.domain;
and
file data/db.domain;
Graham
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: NAMED try to solve domain from old authoritative server
Do you really want help? If so stop obscuring the details. Mark In message CADC-1a0BdZDCGpkyWTDYuj9gj=menjqmxw2usdk4+dxvw_p...@mail.gmail.com, Teerapatr Kittiratanachai writes: Hi List, I have faced the problem. Firstly, I have 2 nameserver, the first nameserver is the authoritative nameserver and not allow the recursive. The second one is the recursive nameserver, and also store zonefile as the same with the first server. I have remove zonefile from the first server and reload named process. It can work normally, I got the SERVFAIL response when I try to query from it. And at the second server, after it remove zone from named.conf and `rndc reload`, it also can query from the new authoritative nameserver. But after a few hours, new TTL is 600, it go back to query from my first server which give me below log. lame-servers: error (unexpected RCODE REFUSED) resolving 'www.domain.tld/A/IN': 192.168.1.1#53 lame-servers: lame server resolving 'www.domain.tld' (in 'domain.tld'?): 2001:db8:0:1::101#53 I must do the `rndc flushname domain.tld` to flush the cache. However a few hours after I flush cache, the problem occur again. Does anyone ever face this problem? My named version is below. #named -V BIND 9.9.2-P1 built with '--localstatedir=/var' '--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' '--without-python' '--with-openssl=/usr' '--with-libxml2=/usr/local' '--without-idn' '--enable-ipv6' '--enable-threads' '--sysconfdir=/etc/namedb' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=x86_64-portbld-freebsd8.2' 'build_alias=x86_64-portbld-freebsd8.2' 'CC=cc' 'CFLAGS=-O2 -pipe -fno-strict-aliasing' 'LDFLAGS= -Wl,-rpath=/usr/lib:/usr/local/lib' 'CPPFLAGS=' 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -pipe -fno-strict-aliasing' using OpenSSL version: OpenSSL 0.9.8q 2 Dec 2010 using libxml2 version: 2.7.8 BR, Te ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Variable in name of file for named.conf
In article mailman.1867.1427927445.26362.bind-us...@lists.isc.org,
Jeff Sadowski jeff.sadow...@gmail.com wrote:
I have a number of slave domains that I would like a naming scheme and
not have to go to each and change the filename.
I have the following zones
zone 1.168.192.in-addr.arpa {
include named.slave;
};
zone 2.168.192.in-addr.arpa {
include named.slave;
};
zone 3.168.192.in-addr.arpa {
include named.slave;
};
zone 4.168.192.in-addr.arpa {
include named.slave;
};
zone 5.168.192.in-addr.arpa {
include named.slave;
};
zone 6.168.192.in-addr.arpa {
include named.slave;
};
zone 7.168.192.in-addr.arpa {
include named.slave;
};
zone 8.168.192.in-addr.arpa {
include named.slave;
};
zone 9.168.192.in-addr.arpa {
include named.slave;
};
zone 10.168.192.in-addr.arpa {
include named.slave;
};
named.slave looks as follows
type slave;
masters {192.168.1.2;};
file data/db.@.slave;
It appears to work on my queries.
nslookup 192.168.1.2
2.1.168.192.in-addr.arpa name = pdc.domain
nslookup 192.168.1.1
1.1.168.192.in-addr.arpa name = gw1.domain
nslookup 192.168.2.1
1.2.168.192.in-addr.arpa name = gw2.domain
the only file created in my data directory seems to be db.@.slave
with the at sign.
Why would you expect anything different? @ only has special meaning
inside zone files, it's not special in named.conf.
Do I really need to have each zone with its own file?
Yes, you do. What's happening is that every time one of the reverse
zones is transferred, it's overwriting that file. But the files are only
used when initializing the zones when named starts up; you get the
correct answers because the in-memory versions of the zones are
distinct. But try restarting named and then see what happens when you do
those nslookups. You'll see that 192.168.1.1 and 192.168.2.1 both return
the same name.
Is there a special syntax to get what I expect?
expected files:
data/db.1.168.192.in-addr.arpa.slave
data/db.2.168.192.in-addr.arpa.slave
data/db.3.168.192.in-addr.arpa.slave
...
data/db.10.168.192.in-addr.arpa.slave
if not I can have Make do it and build some scripts to do what I want
but if there is syntax to do what I want it would be nice.
No, there's no built-in syntax to create the filename based on the zone
name.
--
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
com.google how did they do that
As of the time I am sending this, you can point your browser to http://com.google and get a web page. How did they get com.google to resolve? Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: com.google how did they do that
Am 01.04.2015 um 20:42 schrieb Thomas Schulz: As of the time I am sending this, you can point your browser to http://com.google and get a web page. How did they get com.google to resolve? .google is just another new TLD signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: subdomain with domain
You can do subdomains with the one zone file rather than having separate zones
you just have to put a new ORIGIN for the subdomain.
In the domain file for domain after the SOA and existing records (NS, A,
CNAME etc...) add a line:
$ORIGIN _msdcs.domain.; New subdomain
Then add the records (A, CNAME, SRV etc...) that you want for that subdomain.
(You don't need to add SOA, NS etc... unless they're different for the
subdomain)
Jeffrey C. Lightner
Sr. UNIX Administrator
DS Services of America, Inc.
2300 Windy Ridge
Suite 600 N
Atlanta, GA 30339
P: 770-933-1400 ext.3516
C: 678-772-0018
F: 678-460-3603
E: jlight...@dsservices.com
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Graham Clinch
Sent: Wednesday, April 01, 2015 11:56 AM
To: Jeff Sadowski; bind-users@lists.isc.org
Subject: Re: subdomain with domain
zone _msdcs.domain {
[..]
file data/db.192.168.1.2.slave;
};
zone domain {
[..]
file data/db.192.168.1.2.slave;
};
Both zones are being backed by the same file, so one will be overwriting the
other. This may not be the cause of the half-working situation, but it won't
be helping. Do the bind logs (not sure where Fedora puts them though -
/var/log/messages?) contain any errors?
Unless domain is really '192.168.1.2', I would suggest naming your file after
the zone that it is going to contain - e.g.
file data/db._msdcs.domain;
and
file data/db.domain;
Graham
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: com.google how did they do that
I'm sure it was not cheap. Peanuts compared to their buying .app for $25m. [1] Here's a list of the other TLDs they've got so far: [2] Brace yourself! There are many here now, and more coming. The list of delegated strings [3] increases almost daily, yes. (And I can't stop laughing.) -JP [1] http://www.wired.com/2015/02/is-googles-latest-tld-purchase-a-game-changer/ [2] http://www.google.com/registry/ [3] http://newgtlds.icann.org/en/program-status/delegated-strings ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: com.google how did they do that
In article mailman.1859.1427915221.26362.bind-us...@lists.isc.org, Jan-Piet Mens jpmens@gmail.com wrote: I'm sure it was not cheap. Peanuts compared to their buying .app for $25m. [1] Here's a list of the other TLDs they've got so far: [2] Some of them sound like more April Fools jokes. Brace yourself! There are many here now, and more coming. The list of delegated strings [3] increases almost daily, yes. (And I can't stop laughing.) -JP [1] http://www.wired.com/2015/02/is-googles-latest-tld-purchase-a-game-changer/ [2] http://www.google.com/registry/ [3] http://newgtlds.icann.org/en/program-status/delegated-strings -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: com.google how did they do that
On Wed, Apr 01, 2015 at 02:42:04PM -0400, Thomas Schulz wrote: As of the time I am sending this, you can point your browser to http://com.google and get a web page. How did they get com.google to resolve? I'm sure it was not cheap. Brace yourself! There are many here now, and more coming. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Recall: subdomain with domain
Lightner, Jeff would like to recall the message, subdomain with domain. CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: subdomain with domain
Remember to put check-names ignore to use underlined zones. On Apr 1, 2015, at 4:53 PM, Barry S. Finkel bsfin...@att.net wrote: On 4/1/2015, Jeff Sadowski jeff.sadow...@gmail.com wrote The other day I found that my secondary name servers running bind where not dishing out _msdcs.domain SRV records This was causing join issues. It turned out that the Domain controller had 2 different scopes one for _msdcs.domain and one for domain so I shared the second _msdcs.domain scope with all my bind secondary servers. It would be a good idea to also have the other Active Directory underscore zones: __sites.domain _tcp.domain _udp.domain on your slave server. --Barry Finkel ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND not loading into memory on first transfer
On Fri, Mar 27, 2015 at 8:25 AM, Barry Margolin bar...@alum.mit.edu wrote: In article mailman.1821.1427468103.26362.bind-us...@lists.isc.org, /dev/rob0 r...@gmx.co.uk wrote: On Thu, Mar 26, 2015 at 11:34:42AM -0700, Frank Even wrote: In this particular instance, the masters ended up under maintenance shortly after these boxes rebooted, so they were unable to transfer the zone from them for another 2 hours. These boxes were serving stale data after boot despite being able to accomplish one zone transfer after boot. It seems that failing the first zone transfer did NOT load the zone into memory (but subsequent zone transfers while still failing to write the tmp file DID load the zone into memory). I guess the question really is, is this expected behavior or a bug? The bug is a misconfiguration bug, where contrary to documented requirements, you have not given named write privilege in its directory. I think you're saying named should fail to load the stale zones, which at startup it cannot know are stale. That does not sound correct to me. Perhaps you're suggesting that named should SERVFAIL the zone when the first zone transfer has happened, and while this sounds more reasonable, I am not sure that the zone transfer actually does take place if named is unable to open a temporary file to write. (What would be the point in talking to the master when you know you are unable to handle the data?) He's not suggesting either of these. He's saying that when it successfully transferred the zone, it should update the in-memory version, and serve that, even though it wasn't able to save it to disk. That's what it does on the SECOND transfer, it just doesn't do it on the FIRST transfer. ^^^ THIS! Exactly! I REALIZE I had a configuration problem that prevented writing the zone file locally that snuck in as it turns out on the bind-chroot package update. That's irrelevant to the issue I noticed after that. It DOES load up in memory and serve it up generally. It's just that what I've seen in this particular instance is that it failed to do this on the first successful zone transfer, then loaded it up in memory on the 2nd try (which sadly in this instance, was 2 hours later due to other issues, which of course caused it to be noticed in this instance where it might not have been in previous instances). Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: subdomain with domain
On 4/1/2015, Jeff Sadowski jeff.sadow...@gmail.com wrote The other day I found that my secondary name servers running bind where not dishing out _msdcs.domain SRV records This was causing join issues. It turned out that the Domain controller had 2 different scopes one for _msdcs.domain and one for domain so I shared the second _msdcs.domain scope with all my bind secondary servers. It would be a good idea to also have the other Active Directory underscore zones: __sites.domain _tcp.domain _udp.domain on your slave server. --Barry Finkel ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: subdomain with domain
On 1 April 2015 at 20:53, Barry S. Finkel bsfin...@att.net wrote: It would be a good idea to also have the other Active Directory underscore zones: __sites.domain _tcp.domain _udp.domain on your slave server. From what I've seen in the field, in most AD installations those aren't actual subdomains, Microsoft just uses dotted host names in the main domain. The only subdomain that is always created is the _msdcs subdomain, the rest usually need manual intervention to create them. (The MMC tricks you as it shows folders for subdomains on the dotted host names when they don't actually exist.) To see what domains you actually have configured in Microsoft DNS use dnscmd /enumzones, then replicate those in your secondary. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
