Re: Sites that points their A Record to localhost
On 2014-01-12 10:04, Chris Thompson wrote: On Jan 11 2014, Joseph S D Yao wrote: [...snip...] (2) There is no requirement that a domain name refer to the Web site for that domain. I personally don't like that (for no special reason), and neither apparently does the owner of this domain, who forces people to go to the trouble of typing in www.p3net.net to get to his or her Web site. That would be more plausible if www.p3net.net actually resolved to something, rather than giving NXDOMAIN ... How interesting. From here I see (and saw before I posted): ;; ANSWER SECTION: www.p3net.net. 0 IN A 199.101.28.20 Joe Yao ___ 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: Sites that points their A Record to localhost
On Jan 14 2014, Joseph S D Yao wrote: On 2014-01-12 10:04, Chris Thompson wrote: [...] That would be more plausible if www.p3net.net actually resolved to something, rather than giving NXDOMAIN ... How interesting. From here I see (and saw before I posted): ;; ANSWER SECTION: www.p3net.net. 0 IN A 199.101.28.20 I continue to get NXDOMAIN for www.p3net.net from both of dns1.namesecure.com [205.178.190.56] & dns2.namesecure.com [206.188.198.56]. 199.101.28.20 seems to be search.dnsassist.verizon.net. Are you sure that the nameservers you are using aren't doing "friendly" rewriting of NXDOMAIN responses for you? -- Chris Thompson Email: c...@cam.ac.uk ___ 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: Sites that points their A Record to localhost
Joseph S D Yao wrote: > On 2014-01-12 10:04, Chris Thompson wrote: > > > > That would be more plausible if www.p3net.net actually resolved to > > something, rather than giving NXDOMAIN ... > > How interesting. From here I see (and saw before I posted): > > ;; ANSWER SECTION: > www.p3net.net.0 IN A 199.101.28.20 That IP address indicates that your ISP is lying to you. It belongs to Skye By Nominum which is a cloud DNS service. I guess this is Skye Search since that sounds like a rent-seeking scheme based on replacing NXDOMAINs with advertising. http://www.darkreading.com/nominum-rolls-out-skye-dns-cloud-service/220100568 Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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: Sites that points their A Record to localhost
From: Tony Finch > > ;; ANSWER SECTION: > > www.p3net.net. 0 IN A 199.101.28.20 > > That IP address indicates that your ISP is lying to you. It belongs to > Skye By Nominum which is a cloud DNS service. I guess this is Skye Search > since that sounds like a rent-seeking scheme based on replacing NXDOMAINs > with advertising. > > http://www.darkreading.com/nominum-rolls-out-skye-dns-cloud-service/220100568 Maybe this is why the .berlin TLD is including the copyright notice in their TXT record: https://lists.dns-oarc.net/pipermail/dns-operations/2014-January/011211.html Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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: dumping master file: tmp-xxx: open: permission denied
On 13 Jan 2014, at 20:36 , Mark Andrews wrote: > > In message <8919443e-8f62-48cd-8da4-9c9632fc5...@kreme.com>, LuKreme writes: >> OK, I am getting this error "dumping master file: tmp-xxx: open: >> permission denied", occasionally, on both my slave DNS servers and I >> can't seem to fix it. >> >> The dns slave files are being written into /var/named/etc/namedb/slave >> which is owned by bind >> >> 8 drwxr-xr-x 2 bind wheel 1024 Jan 13 19:46 /var/named/etc/namedb/slave >> >> DNS changes are getting propagated to both servers from the master, so I >> don't know where the permission denied is coming from. Where is this >> tmp file being (attempted to be) written? > > It's trying to write the the working directory which I doubt is > /var/named/etc/namedb/slave. I suspect you have a bad "file" > directive. Hmm. OK, there is a /var/named/etc/namedb/working/ which is also owned by bind. Where might this bad file directive be? The only ‘file’ in named.conf are in the form “slave/example.com” and the pid-file setting. >> And why are the slave servers "dumping master file" in the first place? > > So the slave can start up and serve the zone content when the master > server is down. Oh? Coolness :) -- I WILL STOP TALKING ABOUT THE TWELVE INCH PIANIST Bart chalkboard Ep. 3F07 ___ 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: dumping master file: tmp-xxx: open: permission denied
On Tue, 14 Jan 2014, LuKreme wrote: On 13 Jan 2014, at 20:36 , Mark Andrews wrote: In message <8919443e-8f62-48cd-8da4-9c9632fc5...@kreme.com>, LuKreme writes: OK, I am getting this error "dumping master file: tmp-xxx: open: permission denied", occasionally, on both my slave DNS servers and I can't seem to fix it. The dns slave files are being written into /var/named/etc/namedb/slave which is owned by bind 8 drwxr-xr-x 2 bind wheel 1024 Jan 13 19:46 /var/named/etc/namedb/slave DNS changes are getting propagated to both servers from the master, so I don't know where the permission denied is coming from. Where is this tmp file being (attempted to be) written? It's trying to write the the working directory which I doubt is /var/named/etc/namedb/slave. I suspect you have a bad "file" directive. Hmm. OK, there is a /var/named/etc/namedb/working/ which is also owned by bind. Where might this bad file directive be? The only ‘file’ in named.conf are in the form “slave/example.com” and the pid-file setting. And why are the slave servers "dumping master file" in the first place? So the slave can start up and serve the zone content when the master server is down. Oh? Coolness :) I've been tripped up on this before as there is a default directory and the default can be overridden by a "directory" option statement. Using a chroot adds the current definition into the chrooted directory. It can get quite confusing and I have found that just using full paths on all zone files just cuts out any question. Usually the slave server will get a new copy master fairly quickly if you don't save it but it is cleaner if it has a fairly recent copy locally. Dave -- David Forrest e-mail: drf at maplepark dot com St. Louis, Missouri___ 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: dumping master file: tmp-xxx: open: permission denied
On 14 Jan 2014, at 09:02 , David Forrest wrote:
> On Tue, 14 Jan 2014, LuKreme wrote:
>
>>
>> On 13 Jan 2014, at 20:36 , Mark Andrews wrote:
>>
>>>
>>> In message <8919443e-8f62-48cd-8da4-9c9632fc5...@kreme.com>, LuKreme writes:
OK, I am getting this error "dumping master file: tmp-xxx: open:
permission denied", occasionally, on both my slave DNS servers and I
can't seem to fix it.
The dns slave files are being written into /var/named/etc/namedb/slave
which is owned by bind
8 drwxr-xr-x 2 bind wheel 1024 Jan 13 19:46 /var/named/etc/namedb/slave
DNS changes are getting propagated to both servers from the master, so I
don't know where the permission denied is coming from. Where is this
tmp file being (attempted to be) written?
>>>
>>> It's trying to write the the working directory which I doubt is
>>> /var/named/etc/namedb/slave. I suspect you have a bad "file"
>>> directive.
>>
>> Hmm. OK, there is a /var/named/etc/namedb/working/ which is also owned by
>> bind.
>>
>> Where might this bad file directive be? The only ‘file’ in named.conf are in
>> the form “slave/example.com” and the pid-file setting.
>>
>>> And why are the slave servers "dumping master file" in the first place?
>>>
>>> So the slave can start up and serve the zone content when the master
>>> server is down.
>>
>> Oh? Coolness :)
>
> I've been tripped up on this before as there is a default directory and the
> default can be overridden by a "directory" option statement. Using a chroot
> adds the current definition into the chrooted directory. It can get quite
> confusing and I have found that just using full paths on all zone files just
> cuts out any question. Usually the slave server will get a new copy master
> fairly quickly if you don't save it but it is cleaner if it has a fairly
> recent copy locally.
so I should change
zone "kreme.com" { type slave; masters { 75.148.37.67; }; file
"slave/kreme.com"; };
to
zone "kreme.com" { type slave; masters { 75.148.37.67; }; file
“/var/named/etc/namedb/slave/kreme.com"; };
and that will eliminate the errors?
or are you saying that in options { … I should set
directory “/var/named/etc/namedb/“
If I change the ownership of /var/named/etc/namedb to bind, it gets changed
back to root when bind starts.
--
"Those people who think they know everything are a great annoyance to
those of us who do." - Isaac Asimov
___
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: dumping master file: tmp-xxx: open: permission denied
On Tue, 14 Jan 2014, LuKreme wrote:
On 14 Jan 2014, at 09:02 , David Forrest wrote:
On Tue, 14 Jan 2014, LuKreme wrote:
On 13 Jan 2014, at 20:36 , Mark Andrews wrote:
In message <8919443e-8f62-48cd-8da4-9c9632fc5...@kreme.com>, LuKreme writes:
OK, I am getting this error "dumping master file: tmp-xxx: open:
permission denied", occasionally, on both my slave DNS servers and I
can't seem to fix it.
The dns slave files are being written into /var/named/etc/namedb/slave
which is owned by bind
8 drwxr-xr-x 2 bind wheel 1024 Jan 13 19:46 /var/named/etc/namedb/slave
DNS changes are getting propagated to both servers from the master, so I
don't know where the permission denied is coming from. Where is this
tmp file being (attempted to be) written?
It's trying to write the the working directory which I doubt is
/var/named/etc/namedb/slave. I suspect you have a bad "file"
directive.
Hmm. OK, there is a /var/named/etc/namedb/working/ which is also owned by bind.
Where might this bad file directive be? The only ‘file’ in named.conf are in
the form “slave/example.com” and the pid-file setting.
And why are the slave servers "dumping master file" in the first place?
So the slave can start up and serve the zone content when the master
server is down.
Oh? Coolness :)
I've been tripped up on this before as there is a default directory and the default can
be overridden by a "directory" option statement. Using a chroot adds the
current definition into the chrooted directory. It can get quite confusing and I have
found that just using full paths on all zone files just cuts out any question. Usually
the slave server will get a new copy master fairly quickly if you don't save it but it is
cleaner if it has a fairly recent copy locally.
so I should change
zone "kreme.com" { type slave; masters { 75.148.37.67; }; file
"slave/kreme.com"; };
to
zone "kreme.com" { type slave; masters { 75.148.37.67; }; file
“/var/named/etc/namedb/slave/kreme.com"; };
and that will eliminate the errors?
This works for me. At least I then know where it is going.
or are you saying that in options { … I should set
directory “/var/named/etc/namedb/“
No. this just sets up another redirection to work out. YMMV though
If I change the ownership of /var/named/etc/namedb to bind, it gets changed
back to root when bind starts.
I'm on CentOS65 and it seemed to not notice I was running as named -u named and
this tripped me up too in my init so I added a statement just before it
executes (around line 170 in /etc/rc.d/init.d/named) the start daemon to
change the ownerships to named; like this:
169 chown -hR named:named /var/named ## DRF
170
171 daemon --pidfile "$ROOTDIR/$PIDFILE" /usr/sbin/"$named" -u named ${OPTIONS};
But I am sure there is a proper way to do this. Expediency usually bites.
Maybe some can tell us
--
David Forrest e-mail: drf at maplepark dot com
Maple Park Development http://www.maplepark.com
St. Louis, Missouri
___
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
Can we do a sub-domain delegation with godaddy?
Hi Folks, I am not sure if this is an appropriate forum to answer since more or less it is pertaining to Go Daddy support but since its a huge community our there and I am sure many of them are already using Go Daddy wondering if su-domain delegation is possible in Go Daddy? I mean I have example.com hosted with Go Daddy while I need sub-domain ftp.example.com to be delegated to my internal BIND server. Does any one know how do I do it in Go Daddy? ___ 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
Upgrading from 9.8.3 to 9.9.4
Is there anything I need to know regarding changes in default operation when upgrading from 9.8.3 to 9.9.4? I'm specifically looking for changes that must be addressed in named.conf options in order to keep an upgrade as transparent as possible. Thanks, Mike ___ 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: Upgrading from 9.8.3 to 9.9.4
IIRC, The main change I ran into when I upgraded to 9.9.2-P1 (from 9.7.6-P4) was the change in default for empty-zones. All are enabled by default, including RFC1918 ranges whether you have any defined or not. On 01/14/14 12:16, Mike Bernhardt wrote: > Is there anything I need to know regarding changes in default operation when > upgrading from 9.8.3 to 9.9.4? I'm specifically looking for changes that > must be addressed in named.conf options in order to keep an upgrade as > transparent as possible. > > Thanks, > > Mike > > ___ > 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 > -- Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator For: Enterprise Server Technologies (EST) -- & SafeZone Ally ___ 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: Upgrading from 9.8.3 to 9.9.4
Good call out. I'd always enabled empty-zones so didn't get bit by that, but do think the move to 9.9 is when masterfile-format bit some. Not a big deal if you're aware of it.Other than that the upgrade as quick and painless. I would suggest testing the upgrade on a VM or somewhere first...always good to confirm for your exact configuration. -Original Message- From: "", "P.Eng." Organization: Kansas State University - ITS/Enterprise Server Technologies Date: Tuesday, January 14, 2014 2:46 PM To: "bind-users@lists.isc.org" Subject: Re: Upgrading from 9.8.3 to 9.9.4 >IIRC, The main change I ran into when I upgraded to 9.9.2-P1 (from >9.7.6-P4) was the change in default for empty-zones. All are enabled by >default, including RFC1918 ranges whether you have any defined or not. > >On 01/14/14 12:16, Mike Bernhardt wrote: >> Is there anything I need to know regarding changes in default operation >>when >> upgrading from 9.8.3 to 9.9.4? I'm specifically looking for changes that >> must be addressed in named.conf options in order to keep an upgrade as >> transparent as possible. >> >> Thanks, >> >> Mike >> >> ___ >> 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 >> > >-- >Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator >For: Enterprise Server Technologies (EST) -- & SafeZone Ally >___ >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: dumping master file: tmp-xxx: open: permission denied
On 01/14/2014 08:14 AM, LuKreme wrote:
so I should change
zone "kreme.com" { type slave; masters { 75.148.37.67; }; file
"slave/kreme.com"; };
to
zone "kreme.com" { type slave; masters { 75.148.37.67; }; file
“/var/named/etc/namedb/slave/kreme.com"; };
and that will eliminate the errors?
No. All path names in your configuration file should be relative to the
chroot directory. So /etc/namedb/slave/kreme.com.
You seem to be using FreeBSD. The default named.conf has the
configuration you should start with if you're using the default rc.d
script to start named. Start with that, follow the examples, and only
change things in the default if you're certain you know what the
implications of those changes will be.
Doug
___
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: Sites that points their A Record to localhost
If the domain owner *really* feels that they have to publish *some* address record for a particular name, but there is no available service at that name, then the null or "unspecified" address (IPv4 = 0.0.0.0, IPv6 = ::0) is the appropriate value to put there. Loopback is anti-social; an apparent attempt to make the client waste resources connecting to itself. In legal terms, one might call this an "attractive nuisance". - Kevin P.S. I wish more load-balancer vendors would understand, appreciate and adopt the use of the null/unspecified address to mean "no service available here". P.P.S. I credit Mark Andrews for opening my eyes to the proper use of null/unspecified. On 1/10/2014 11:36 PM, Joseph S D Yao wrote: On 2014-01-10 15:01, Eduardo Bonsi wrote: ... It seems like they have their domain configuration A Record pointed to the localhost. We all know that the localhost is not routable outside of the internet. Therefore I am sure their website cannot resolve out of the 127.0.0.1. In addition to that, it is possible that this is happening only here because of the way our Server configuration is setup in the OS X to bring the resolver to the localhost first before it can go out to the distributed domains/websites through the Apache conf. ... There seems to be a pile of misconceptions here. (1) There is no requirement at all that a domain name have an A record. It does not have to resolve to an IP address at all. It only has to have an SOA record and an NS record (preferably more than one); and not even that, if it is a subdomain that is not a separate zone. (2) There is no requirement that a domain name refer to the Web site for that domain. I personally don't like that (for no special reason), and neither apparently does the owner of this domain, who forces people to go to the trouble of typing in www.p3net.net to get to his or her Web site. Incidentally, there is no requirement that the domain name refer to a mail server, either (which used to be common before the Web existed), or to an FTP server, or to a Telnet server, or to a nuclear reactor control device. Or to anything. (3) However, any name MAY resolve to any IP address, routable or not. That doesn't mean there's anything useful, or even related to that domain, at that IP address. (4) "127.0.0.1" is the IP equivalent of the English language word "me". If I say, "me", I am referring to myself. If you say, "me", you are referring to yourself. It cannot be used to direct anyone to somewhere else. In fact, some use it to deflect probers AWAY from themselves, and back on the prober's own server. (E.g., if I wanted to probe "p3net.net", my server would be probing itself!) (5) 127.0.0.1 is not among the IP addresses mislabeled as "unroutable". It is always routable. To right here. Well, for you, right there. (6) Just because OS X has 127.0.0.1 as the resolver has no effect on what that resolver returns. Don't confuse the concepts. I think there were some others, but it's getting late. Joe Yao ___ 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: Can we do a sub-domain delegation with godaddy?
On 2014-01-14 12:39, Blason R wrote: Hi Folks, I am not sure if this is an appropriate forum to answer since more or less it is pertaining to Go Daddy support but since its a huge community our there and I am sure many of them are already using Go Daddy wondering if su-domain delegation is possible in Go Daddy? I mean I have example.com [1] hosted with Go Daddy while I need sub-domain ftp.example.com [2] to be delegated to my internal BIND server. Does any one know how do I do it in Go Daddy? ... (1) the same way you do it with any other delegation using any other name server. You put the same list of name servers that are in your zone, in the parent zone, together with any needed "glue" records. "Glue" records are A records for any name servers that are in the delegated domain or any domain under the delegated domain. (2) However, if you are delegating to an INTERNAL-only name server then you should not be delegating. Delegation is for information that you want to share with everyone seeing the delegation. (3) Your choice of names is interesting. Usually ftp.example.com would be a single server with a single A record. But if you want it to have its own separate zone file on a separate server, with an SOA record and a list of NS records, that is certainly allowable in DNS. Maybe you will then declare chi.ftp.example.com and nyc.ftp.example.com and dca.ftp.example.com and ... EXAMPLE: zone.ftp.example.com: $TTL1h @ SOA ... NS ns1.ftp.example.com. NS ns1.chi.ftp.example.com. NS ns3.isc.org. ns1 A 6.7.8.9 ns1.chi A 6.9.8.7 You ask GoDaddy to add the following to the "example.com" zone file: NS ns1.ftp.example.com. NS ns1.chi.ftp.example.com. NS ns3.isc.org. ; Glue record ns1.ftp A 6.7.8.9 ; Glue record ns1.chi.ftp A 6.9.8.7 Joe Yao ___ 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: Sites that points their A Record to localhost
On 2014-01-14 09:56, Chris Thompson as IP Register wrote: ... 199.101.28.20 seems to be search.dnsassist.verizon.net. Are you sure that the nameservers you are using aren't doing "friendly" rewriting of NXDOMAIN responses for you? ... Ack. Good thing you can't see how embarrassed I'm blushing. That's exactly right. At some point my ISP router/switch had to be reset to clear some major malfeasance and I never went back into it and "corrected" its default DNS servers again. Derned lying cheating scoundrel of a network device. The shamed Joseph Yao ___ 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
