Reverse DNS conditional forwardning
Hi Everyone I have problem because my business need is to forward reverse lookup query for IPs which are in same time hosted on my local name server. That means few IPs from reverse zone of subnet for example 172.30.115.0/24 I need to forward to remote name server to get response with different suffix as Im getting locally ony DNS. That is possible that Bind can make conditional forwardning for reverse zone just for few records and all others IPs from above subnet can be hosted on my local DNS in same time? Thank you Wysłano z usługi Yahoo Poczta w systemie 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
Impossible to activate logging
under systemd, and under a lxd stretch container in a minimal stretch host. I get : Jan 18 10:21:13 bind named[893]: command channel listening on ::1#953 Jan 18 10:21:13 bind named[893]: isc_file_isplainfile '/var/log/bind/bind.log' failed: permission denied Jan 18 10:21:13 bind named[893]: configuring logging: permission denied Jan 18 10:21:13 bind named[893]: loading configuration: permission denied Jan 18 10:21:13 bind named[893]: exiting (due to fatal error) ... And I do not use apparmor and : root@bind:~# ls -lh /var/log total 512K -rw-r--r-- 1 root root 7.9K Dec 22 12:19 alternatives.log drwxr-xr-x 1 root root 60 Dec 23 00:09 apt drwxrwxrwx 1 bind bind 16 Jan 18 09:22 bind -rw-r--r-- 1 root root 262K Oct 21 00:48 bootstrap.log -rw--- 1 root utmp 4.2K Jan 16 07:46 btmp -rw-r--r-- 1 root root 129K Dec 23 00:09 dpkg.log -rw-r--r-- 1 root root 3.4K Dec 22 12:20 faillog -rw-rw-r-- 1 root utmp 31K Jan 18 07:35 lastlog -rw-rw-r-- 1 root utmp 88K Jan 18 07:35 wtmp root@bind:~# ls -lh /var/log/bind/ total 4.0K -rwxrwxrwx 1 bind bind 217 Jan 18 09:22 bind.log Any help welcome, Thanks PV ___ 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: Reverse DNS conditional forwardning
On 18.01.18 09:32, Karol Nowicki via bind-users wrote: I have problem because my business need is to forward reverse lookup query for IPs which are in same time hosted on my local name server. That means few IPs from reverse zone of subnet for example 172.30.115.0/24 I need to forward to remote name server to get response with different suffix as Im getting locally ony DNS. That is possible that Bind can make conditional forwardning for reverse zone just for few records and all others IPs from above subnet can be hosted on my local DNS in same time? what you search for is the Classless IN-ADDR.ARPA delegation, described in RFC2317 -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "To Boot or not to Boot, that's the question." [WD1270 Caviar] ___ 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: Impossible to activate logging
On 18/01/2018 11:36, Pierre Couderc wrote: Hi Pierre, > under systemd, and under a lxd stretch container in a minimal stretch host. > > I get : > > Jan 18 10:21:13 bind named[893]: command channel listening on ::1#953 > Jan 18 10:21:13 bind named[893]: isc_file_isplainfile > '/var/log/bind/bind.log' failed: permission denied > Jan 18 10:21:13 bind named[893]: configuring logging: permission denied > Jan 18 10:21:13 bind named[893]: loading configuration: permission denied > Jan 18 10:21:13 bind named[893]: exiting (due to fatal error) > ... > > And I do not use apparmor and : > > root@bind:~# ls -lh /var/log > total 512K > -rw-r--r-- 1 root root 7.9K Dec 22 12:19 alternatives.log > drwxr-xr-x 1 root root 60 Dec 23 00:09 apt > drwxrwxrwx 1 bind bind 16 Jan 18 09:22 bind > -rw-r--r-- 1 root root 262K Oct 21 00:48 bootstrap.log > -rw--- 1 root utmp 4.2K Jan 16 07:46 btmp > -rw-r--r-- 1 root root 129K Dec 23 00:09 dpkg.log > -rw-r--r-- 1 root root 3.4K Dec 22 12:20 faillog > -rw-rw-r-- 1 root utmp 31K Jan 18 07:35 lastlog > -rw-rw-r-- 1 root utmp 88K Jan 18 07:35 wtmp > root@bind:~# ls -lh /var/log/bind/ > total 4.0K > -rwxrwxrwx 1 bind bind 217 Jan 18 09:22 bind.log I don't know what the function "isc_file_isplainfile" checks for, but perhaps the executable bits on the file are causing the failure. Log files shouldn't be executable, so you normally need mode 0644 for them. Try changing the mode, and seeing if that helps. Regards, Anand ___ 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: [ASK] Block Malware Generate Random Subdomain, Domain and TLD
Grant Taylor via bind-users wrote: > > Did you see or hear any talks about RPS in addition to RPZ? I'm afraid not - I guess it's still too new. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode German Bight, Humber, Thames: North or northwest 7 to severe gale 9 backing west 5 or 6, occasionally 4 in German Bight. Rough or very rough becoming slight or moderate. Rain then wintry showers. Moderate or good occasionally poor. ___ 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: intermittent SERVFAIL for high visible domains such as *.google.com
Brian J. Murrell wrote: > > In any case when this happens, it will last a few minutes until it > resolves itself and/or I issue an "rndc reload". That always seems to > correct it if I don't care to wait it out. Does the time to recovery correspond to the lame-ttl setting? The default is 10 minutes - try reducing it and see if the outage becomes shorter. When you have a failure, try `rndc flushtree` to more selectively drop problematic state - you might have to find out the nameservers of the broken domain and flush them. (The google.com nameservers are under google.com; GitHub's are under dynect.net and a bunch of awsdns domains.) > I have a db dump (rndc dumpdb) as well as some trace (rndc trace x10) > while this is happening. Is this enough? If so, what should I look > for as a cause of the SERVFAILs? The trace might tell you where the SERVFAIL came from - you'll need to read it carefully to work out how named handled the problem query. This might or might not tell you the cause, depending on how clearly the gun is smoking. Look at the end of the dump - the address database, bad cache, and servfail cache. > Do I need tracing enabled before the situation happens? That will make it a lot easier, yes :-) > What level (how many "rndc trace"s should I run)? You can specify a number directly, like `rndc trace 11` - level 11 is handy because it includes query and response packet dumps (er, but that is a 9.11 feature - in 9.9 you'll only get the response packets). Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Trafalgar: North or northeast 5 to 7. High, becoming very rough. Fair. 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: intermittent SERVFAIL for high visible domains such as *.google.com
On Thu, 2018-01-18 at 15:41 +, Tony Finch wrote: > > Does the time to recovery correspond to the lame-ttl setting? I am not sure. I'm not always aware of when it starts. I guess if I am running a trace level permanently the log would tell me though. > The default > is 10 minutes - try reducing it and see if the outage becomes > shorter. If it does, what is that telling me? The problem domains are listing NSes that don't actually host the zone? I thought named normally logged lame delegations but I don't see a single one in the last few days. That said, if such a high-visibility domain as googles were misconfigured, it would be wreaking havoc all over the Internet, and drawing lots of attention wouldn't it? > When you have a failure, try `rndc flushtree` to more selectively > drop > problematic state - you might have to find out the nameservers of the > broken domain and flush them. (The google.com nameservers are under > google.com; GitHub's are under dynect.net and a bunch of awsdns > domains.) rndc flushtree takes a domain name though doesn't it? In what case would I need to find nameservers? So, when I do rndc reload am I flushing the cache? :-( > Look at the end of the dump - the address database, ; Address database dump ... ; ns3.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] ; ns2.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] ; ns1.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] ; ns4.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] > bad cache, Empty. > and > servfail cache. Non-existent section in my database dump. > > Do I need tracing enabled before the situation happens? > > That will make it a lot easier, yes :-) > > > What level (how many "rndc trace"s should I run)? > > You can specify a number directly, like `rndc trace 11` - level 11 is > handy because it includes query and response packet dumps (er, but > that > is a 9.11 feature - in 9.9 you'll only get the response packets). I'll set that trace now and hope to hit the problem again soon -- before I fill up my filesystem. :-) Cheers, b. signature.asc Description: This is a digitally signed message part ___ 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: Reverse DNS conditional forwardning
On 01/18/2018 03:44 AM, Matus UHLAR - fantomas wrote: what you search for is the Classless IN-ADDR.ARPA delegation, described in RFC2317 Classless IN-ADDR.ARPA delegation likely won't work if all IPs involved are not configured for it. I would suggest adding NS records to (re)delegate the (few?) IPs in question back to the proper name server. I.e. ; Mach Global zone file $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (2002040800 30m 15m 1w 1w) 1 IN PTR host1.example.net. 2 IN PTR host2.example.net. ; … 42 IN PTR host42.example.net. ; … ; Mach local zone file $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA myLocalServer.myLocalDomain.myTld. myEmail.myPublicDomain.myTld. (2002040800 30m 15m 1w 1w) 1 IN PTR client1.myLocalDomain.myTld. 2 IN PTR client2.myLocalDomain.myTld. ; … 42 IN NS blackhole-1.iana.org. 42 IN NS blackhole-2.iana.org. ; … 96 IN PTR server3.myLocalDomain.myTld. 97 IN PTR oldServer3.myLocalDomain.myTld. ; … This might not be an up and up proper delegation, but every time I've used this technique it has worked for me. Further, it does not require the complexities of RFC 2317 Classless IN-ADDR.ARPA delegation, including the parent zone configured to support it. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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: Impossible to activate logging
On 01/18/2018 01:01 PM, Anand Buddhdev wrote: I don't know what the function "isc_file_isplainfile" checks for, but perhaps the executable bits on the file are causing the failure. Log files shouldn't be executable, so you normally need mode 0644 for them. Try changing the mode, and seeing if that helps. Thnk you I have tried all possible combiations without success ___ 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: intermittent SERVFAIL for high visible domains such as *.google.com
Brian J. Murrell wrote: > On Thu, 2018-01-18 at 15:41 +, Tony Finch wrote: > > > > The default is 10 minutes - try reducing it and see if the outage > > becomes shorter. > > If it does, what is that telling me? My hypothesis here is that `named` has marked all the nameservers for the domain that is failing as lame, so it no longer has anywhere to send queries for the domain, so it returns a SERVFAIL. The address database dump confirms this guess, so there isn't any need to fiddle with the lame-ttl unless you want to double check. > > When you have a failure, try `rndc flushtree` to more selectively drop > > problematic state - you might have to find out the nameservers of the > > broken domain and flush them. (The google.com nameservers are under > > google.com; GitHub's are under dynect.net and a bunch of awsdns > > domains.) > > rndc flushtree takes a domain name though doesn't it? In what case > would I need to find nameservers? The idea is to flush the state needed to resolve queries for the domain, so as well as flushing the domain itself, you also need to flush its nameservers - easy for Google, harder for GitHub. > So, when I do rndc reload am I flushing the cache? :-( No, a reload will (in almost all cases) retain the cache - though it might clear other state (I have not checked exactly what). I'm a bit surprised it fixes your problem; maybe the address database gets flushed on a reload. > ; Address database dump > ... > ; ns3.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] > ; ns2.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] > ; ns1.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] > ; ns4.google.com [v4 TTL 7] [v6 TTL 7] [v4 failure] [v6 failure] OK, here's a very smoky gun. I think this suggests that you have some kind of connectivity problem between your DNS server and Google's (etc) - you should check that large fragmented EDNS responses get through OK, and that TCP works OK, and that you don't have pMTUd problems. > > and servfail cache. > > Non-existent section in my database dump. Ah, the servfail cache is another 9.11 feature. Tony. -- f.anthony.n.finchhttp://dotat.at/ - I xn--zr8h punycode Hebrides, Bailey, Fair Isle, Faeroes: Cyclonic, mainly west, 5 to 7. Rough or very rough, occasionally moderate in Fair Isle and Faeroes. Squally wintry showers. Good occasionally poor. ___ 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: Reverse DNS conditional forwardning
On 01/18/2018 03:44 AM, Matus UHLAR - fantomas wrote: what you search for is the Classless IN-ADDR.ARPA delegation, described in RFC2317 On 18.01.18 09:39, Grant Taylor via bind-users wrote: Classless IN-ADDR.ARPA delegation likely won't work if all IPs involved are not configured for it. you can create something very similar, not necessarily classless. simply redirect reverse names via CNAME to other zone. very standard. I would suggest adding NS records to (re)delegate the (few?) IPs in question back to the proper name server. I.e. ; Mach Global zone file $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA prisoner.iana.org. hostmaster.root-servers.org. (2002040800 30m 15m 1w 1w) 1 IN PTR host1.example.net. 2 IN PTR host2.example.net. ; … 42 IN PTR host42.example.net. ; … ; Mach local zone file $ORIGIN 2.0.192.in-addr.arpa. @ IN SOA myLocalServer.myLocalDomain.myTld. myEmail.myPublicDomain.myTld. (2002040800 30m 15m 1w 1w) 1 IN PTR client1.myLocalDomain.myTld. 2 IN PTR client2.myLocalDomain.myTld. ; … 42 IN NS blackhole-1.iana.org. 42 IN NS blackhole-2.iana.org. what's the point of redirecting reverse DNS to blackholes? ; … 96 IN PTR server3.myLocalDomain.myTld. 97 IN PTR oldServer3.myLocalDomain.myTld. ; … This might not be an up and up proper delegation, but every time I've used this technique it has worked for me. Further, it does not require the complexities of RFC 2317 Classless IN-ADDR.ARPA delegation, including the parent zone configured to support it. you just showed how parent zone (2.0.192.in-addr.arpa) must be configured for it. what you describe is how dj bernstein proposed reverse delegation. However it's much better to define subzone and redirect records via CNAMEs to it. it's easier to define one subzone with a few NS records pointing to it and replace each PTR with CNAME than replace each PTR with multiple NSes. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved! ___ 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
NS ROOT queries to root servers
Hi all,
we are running BIND in linux servers. We are using release
bind-9.9.4-51.el7_4.1.x86_64
We are not using BIND in an standard Internet environment. Instead, we are
using BIND in a mobile network environment, in which DNS Root service is
provided by service providers. Therefore, we are no using built-in root
servers. So, we have customized the content of db.root file to include IP
addresses of DNS servers belonging to our service provider. In our case we have
configuration similar to the following one (we have omitted real server names
and IP addresses):
. 360 IN NS SERVER1.grx.
SERVER1.grx. 360 IN A 10.10.10.1
. 360 IN NS SERVER2.grx.
SERVER2.grx. 360 IN A 10.10.20.1
. 360 IN NS SERVER3.grx.
SERVER3.grx. 360 IN A 10.10.30.1
. 360 IN NS SERVER4.grx.
SERVER4.grx. 360 IN A 10.10.40.1
. 360 IN NS SERVER5.grx.
SERVER5.grx. 360 IN A 10.10.50.1
. 360 IN NS SERVER6.grx.
SERVER6.grx. 360 IN A 10.10.60.1
We have noticed that each query forwarded towards root servers creates an extra
NS ROOT query. We have been reading about "root priming", so were expecting
this NS ROOT query upon server restart. However, we are seeing this kind of
query for each query that has to be resolved with root servers assistance. We
believed that "root priming" was supposed to happen once a day or upon ROOT
SERVER TTL, which in our case is 3600, i.e., our root servers are replying with
TTL 3600 to NS ROOT queries.
In addition, we have also tested with DNSSEC disabled as follows:
dnssec-enable no;
dnssec-validation no;
Disabling DNSSEC has not made any difference.
How can we stop/limit these massive NS ROOT queries?
In addition, we are going to configure a second provider that has warned us on
they do not reply to NS ROOT queries. Could this pose a problem for our DNS
servers? Is it possible to instruct our DNS servers not to perform root priming?
Thanks for your help.
Kind regards,
Antonio.
P.S. Below you can find the structure of our named.conf file
acl "ExternalACL" {any;};
acl "InternalACL" {10.10.100.1/32;10.10.200.1/32; };
options {
allow-recursion {10.10.100.1/32;10.10.200.1/32;};
directory "/var/named";
};
view "InternalView" IN {
match-clients {InternalACL;};
allow-recursion {10.10.100.1/32;10.10.200.1/32;};
zone "." IN {
type hint;
file "db.root";
};
# Master Zone(s):
MASTER ZONES
};
view "ExternalView" IN {
allow-recursion {127.0.0.1;};
allow-transfer {none;};
match-clients {key
gibraltar-externalview-smkey;!gibraltar-externalview-other-smkeys;ExternalACL;};
zone "." IN {
type hint;
file "db.root";
};
# Master Zone(s):
MASTER ZONES
};
Antonio Medina Ortega
Analyst
Broadband & Transport Networks
Gibtelecom
Mob: +350 58008261
Fax: +350 20071673
Email: antonio.med...@gibtele.com
Web: www.gibtele.com
Re: Reverse DNS conditional forwardning
On 01/18/2018 12:08 PM, Matus UHLAR - fantomas wrote: you can create something very similar, not necessarily classless. simply redirect reverse names via CNAME to other zone. very standard. Yes. But that requires that something is done in the authoritative / parent zone. what's the point of redirecting reverse DNS to blackholes? I was using blackholes as the example, which should be accurate for the 192.0.2.0/24 test network. Adjust contents to reflect your needs. you just showed how parent zone (2.0.192.in-addr.arpa) must be configured for it. No, I did not. The following zone is the authoritative zone, as seen by the world. ; Mach Global zone file $ORIGIN 2.0.192.in-addr.arpa. @INSOAprisoner.iana.org. hostmaster.root-servers.org. (2002040800 30m 15m 1w 1w) 1INPTRhost1.example.net. 2INPTRhost2.example.net. ; … 42INPTRhost42.example.net. ; … Note that nothing has been done in the authoritative zone. The following is the zone that would go on the local server that would override the globally authoritative zone. ; Mach local zone file $ORIGIN 2.0.192.in-addr.arpa. @INSOAmyLocalServer.myLocalDomain.myTld. myEmail.myPublicDomain.myTld. (2002040800 30m 15m 1w 1w) 1INPTRclient1.myLocalDomain.myTld. 2INPTRclient2.myLocalDomain.myTld. ; … 42INNSblackhole-1.iana.org. 42INNSblackhole-2.iana.org. ; … 96INPTRserver3.myLocalDomain.myTld. 97INPTRoldServer3.myLocalDomain.myTld. ; … This local copy is where the changes are made to override what the globally authoritative zone serves. (Like I think the OP was indicating s/he was doing.) The NS records for 42 in the local zone ""delegate back to the parent servers. blackhole-[12].iana.org happen to be the NS servers for the example zone. Modify as appropriate for what you want to do. what you describe is how dj bernstein proposed reverse delegation. I was not aware of that. I'll have to look into his proposed solution. However it's much better to define subzone and redirect records via CNAMEs to it. it's easier to define one subzone with a few NS records pointing to it and replace each PTR with CNAME than replace each PTR with multiple NSes. I'm going to have to disagree with you. I have used both RFC 2317 Classless IN-ADDR.ARPA (type) delegation and the delegation that I'm suggesting multiple times. Every time I've used Classless IN-ADDR.ARPA (type) delegation has resulted in heartache or worse. I've even personally experienced cases where Spam RBLs failed miserably with RFC 2317 Classless IN-ADDR.ARPA and ended up black listing things inappropriately. I have had zero problems with the type of delegation that I'm advocating. Combining the fact that 2317 Classless IN-ADDR.ARPA (type) delegation requires support in the authoritative / parent zone with the problems that I've seen and the fact that I've not seen any problems with my alternate, I'll continue using my alternate. As a bonus, it's entirely possible to do cross delegation using my method without any problems. I can have two clients using /25, each cross delegating the others part, and things work out quite well. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic 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
