CAA RR type
Hi. I have zone file as follows $ORIGIN rameshtest-caa.com. $TTL 86400 ; 1 day @ IN SOA ns1.rameshtest-caa.com. root.rameshtest-caa.com. ( 2009040114 ; serial 3600 ; refresh (1 hour) 900; retry (15 minutes) 1814400; expire (3 weeks) 900; minimum (15 minutes) ) IN NS ns1.rameshtest-caa.com. IN A 1.1.1.1 ns1 IN A 1.2.3.4 a IN A 2.2.2.2 IN 3FFE:0B80:0444:0004::::0004 caa IN CAA 0 issue "ca.example.net" caa1IN CAA 0 iodef "mailto:secur...@example.com"; caa2IN CAA 0 iodef "http://iodef.example.com/"; When I start named, getting the following error: /var/named/zones/rameshtest-caa.com:15: unknown RR type 'CAA' /var/named/zones/rameshtest-caa.com:16: unknown RR type 'CAA' /var/named/zones/rameshtest-caa.com:17: unknown RR type 'CAA' zone rameshtest-caa.com/IN: loading from master file /var/named/zones/ rameshtest-caa.com failed: unknown class/type _default/rameshtest-caa.com/IN: unknown class/type [FAILED] I am using bind 9.6. Did I miss/mistake anything here? Could you please guide me to work for CAA. Thanks & Regards, Ramesh ___ 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: CAA RR type
On Fri, May 15, 2015 at 12:39:21PM +0530, rams wrote: > I am using bind 9.6. Did I miss/mistake anything here? Could you > please guide me to work for CAA. BIND 9.6 is unsupported. Please use a current version of BIND. Mukund pgpWkn0oAFeYC.pgp Description: PGP 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: CAA RR type
Thank You Mukund . I figured that it is implemented in 9.10 Regards, Ramesh On Fri, May 15, 2015 at 12:54 PM, Mukund Sivaraman wrote: > On Fri, May 15, 2015 at 12:39:21PM +0530, rams wrote: > > I am using bind 9.6. Did I miss/mistake anything here? Could you > > please guide me to work for CAA. > > BIND 9.6 is unsupported. Please use a current version of BIND. > > Mukund > ___ 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: CAA RR type
In message , rams writes: > Hi. > I have zone file as follows > > $ORIGIN rameshtest-caa.com. > $TTL 86400 ; 1 day > @ IN SOA ns1.rameshtest-caa.com. > root.rameshtest-caa.com. ( > 2009040114 ; serial > 3600 ; refresh (1 hour) > 900; retry (15 minutes) > 1814400; expire (3 weeks) > 900; minimum (15 minutes) > ) > IN NS ns1.rameshtest-caa.com. > IN A 1.1.1.1 > ns1 IN A 1.2.3.4 > a IN A 2.2.2.2 > IN 3FFE:0B80:0444:0004::::0004 > caa IN CAA 0 issue "ca.example.net" > caa1IN CAA 0 iodef "mailto:secur...@example.com"; > caa2IN CAA 0 iodef "http://iodef.example.com/"; > > When I start named, getting the following error: > > /var/named/zones/rameshtest-caa.com:15: unknown RR type 'CAA' > /var/named/zones/rameshtest-caa.com:16: unknown RR type 'CAA' > /var/named/zones/rameshtest-caa.com:17: unknown RR type 'CAA' > zone rameshtest-caa.com/IN: loading from master file /var/named/zones/ > rameshtest-caa.com failed: unknown class/type > _default/rameshtest-caa.com/IN: unknown class/type >[FAILED] > > > I am using bind 9.6. Did I miss/mistake anything here? Could you please > guide me to work for CAA. > > Thanks & Regards, > Ramesh Use a recent (supported) version of BIND. CAA was published Jan 2013. BIND 9.6.0 was released Dec 2008. CAA Support was added to BIND at these release points: BIND 9.8.8 (BIND 9.8.x is at EoL) BIND 9.9.6 BIND 9.10.1 Mark -- 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: CAA RR type
Thank You Mark. Now I am using 9.9 and It is working fine. Regards, Ramesh On Fri, May 15, 2015 at 12:59 PM, Mark Andrews wrote: > > In message owv0s7...@mail.gmail.com>, rams writes: > > Hi. > > I have zone file as follows > > > > $ORIGIN rameshtest-caa.com. > > $TTL 86400 ; 1 day > > @ IN SOA ns1.rameshtest-caa.com. > > root.rameshtest-caa.com. ( > > 2009040114 ; serial > > 3600 ; refresh (1 hour) > > 900; retry (15 minutes) > > 1814400; expire (3 weeks) > > 900; minimum (15 minutes) > > ) > > IN NS ns1.rameshtest-caa.com. > > IN A 1.1.1.1 > > ns1 IN A 1.2.3.4 > > a IN A 2.2.2.2 > > IN 3FFE:0B80:0444:0004::::0004 > > caa IN CAA 0 issue "ca.example.net" > > caa1IN CAA 0 iodef "mailto:secur...@example.com"; > > caa2IN CAA 0 iodef "http://iodef.example.com/"; > > > > When I start named, getting the following error: > > > > /var/named/zones/rameshtest-caa.com:15: unknown RR type 'CAA' > > /var/named/zones/rameshtest-caa.com:16: unknown RR type 'CAA' > > /var/named/zones/rameshtest-caa.com:17: unknown RR type 'CAA' > > zone rameshtest-caa.com/IN: loading from master file /var/named/zones/ > > rameshtest-caa.com failed: unknown class/type > > _default/rameshtest-caa.com/IN: unknown class/type > >[FAILED] > > > > > > I am using bind 9.6. Did I miss/mistake anything here? Could you please > > guide me to work for CAA. > > > > Thanks & Regards, > > Ramesh > > Use a recent (supported) version of BIND. > > CAA was published Jan 2013. > BIND 9.6.0 was released Dec 2008. > > CAA Support was added to BIND at these release points: > > BIND 9.8.8 (BIND 9.8.x is at EoL) > BIND 9.9.6 > BIND 9.10.1 > > Mark > -- > 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: shutting up logs
Am 15.05.2015 um 08:56 schrieb G.W. Haywood: Hi there, On Fri, 15 May 2015, Reindl Harald wrote: Am 15.05.2015 um 02:01 schrieb Nick Edwards: > skipping nameserver 'ns5.concord.org' because it is a CNAME, while > resolving '210.128-25.119.138.63.in-addr.arpa/PTR' > > I have logs grow by about 30 megs a day with pretty much only this in > it (of course not always same remote server), how do I shut this up ? > ... you can't ... You can. If you use syslog-ng you can do anything you like, for example you can filter messages using regular expressions. If there wasn't a syslog-ng, I'd have to write one that's a completly different thing while rsyslog can do the same, but that don't stop named to produce the message, it's just thrown away by the syslog-daemon while the OP didn't say he forwards logs to syslogd 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
Bind DLZ
Hi all, I've been using Bind DLZ for quite some time now - the original Sourceforge code in various older versions of bind - and have had no issues with it. So as to move away from hand patching code and building custom packages I've tried to move to the packaged version of bind included in Centos 7. For the most part DLZ is working as per the older version/code but wildcard handling seems to have changed and is no longer working as it did. EG. we have a number of domains with entries such as *.testing IN A so.m.e.ip. A lookup of ver21.testing.somedomain.co.uk in Bind 9.3.6 with bind & SourceForge DLZ returns the correct A so.m.e.ip. Bind 9.9.4 returns not found. If I use static zone files with 9.9.4 it resolves as expected. Debugging bind 9.9.4 seems to show that the only wilcard search it performs is for *.somedomain.co.uk it does not iterate through the possible sub hosts/domains. Is this a bug or by design and if by design why? -- Best regards, Rob Hall ___ 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
R: R: RPZ and client matching
Hello, very interesting feature: >>We have prepared a branch that adds an "rpz-skipzone." policy action >>that, when matched by the trigger, behaves as if the current policy zone >>is disabled, and proceeds to the next one. It is still in the early >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: R: R: RPZ and client matching
Hi Job On Fri, May 15, 2015 at 04:56:07PM +0200, Job wrote: > Hello, > > very interesting feature: > > >>We have prepared a branch that adds an "rpz-skipzone." policy action > >>that, when matched by the trigger, behaves as if the current policy zone > >>is disabled, and proceeds to the next one. It is still in the early > > > But, actually there is a feature called "rpz-passthru". > It is similar or something different? rpz-passthru. skips further RPZ processing when that trigger matches. rpz-skipzone. skips to the next policy zone in order. So, for example, you could have a zone that looks like this: zone1: ; move these specific clients to the next policy zone 32.z.y.x.w.rpz-client-ip IN CNAME rpz-skipzone. 32.d.c.b.a.rpz-client-ip IN CNAME rpz-skipzone. ; pass through all other addresses 0.0.0.0.0.rpz-client-ip IN CNAME rpz-passthru. zone2: ; Handle clients that were moved here 0.0.0.0.0.rpz-client-ip IN ... Right now the branch has not been reviewed yet. Once it is reviewed, I'll let you know and you can try it from the master branch of BIND. (It will not be backported to 9.10 as it's a new feature that's not essential for DNS.) Mukund pgpxPIh2_Abn1.pgp Description: PGP 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
R: R: R: RPZ and client matching
Hi Mukund! I am very glad to try the features. Is there a way to assign a policy-zone to a list of client ip without excluding/passing them through? Simply assigning ip to RPZ policy zone! Thank you, Francesco Da: Mukund Sivaraman [m...@isc.org] Inviato: venerdì 15 maggio 2015 17.16 A: Job Cc: bind-users@lists.isc.org Oggetto: Re: R: R: RPZ and client matching Hi Job On Fri, May 15, 2015 at 04:56:07PM +0200, Job wrote: > Hello, > > very interesting feature: > > >>We have prepared a branch that adds an "rpz-skipzone." policy action > >>that, when matched by the trigger, behaves as if the current policy zone > >>is disabled, and proceeds to the next one. It is still in the early > > > But, actually there is a feature called "rpz-passthru". > It is similar or something different? rpz-passthru. skips further RPZ processing when that trigger matches. rpz-skipzone. skips to the next policy zone in order. So, for example, you could have a zone that looks like this: zone1: ; move these specific clients to the next policy zone 32.z.y.x.w.rpz-client-ip IN CNAME rpz-skipzone. 32.d.c.b.a.rpz-client-ip IN CNAME rpz-skipzone. ; pass through all other addresses 0.0.0.0.0.rpz-client-ip IN CNAME rpz-passthru. zone2: ; Handle clients that were moved here 0.0.0.0.0.rpz-client-ip IN ... Right now the branch has not been reviewed yet. Once it is reviewed, I'll let you know and you can try it from the master branch of BIND. (It will not be backported to 9.10 as it's a new feature that's not essential for DNS.) Mukund ___ 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
Future of BIND's built-in empty zone list
On Thursday, May 14, 2015, Rob Foehl > wrote: > On Thu, 14 May 2015, Chris Thompson wrote: > > Now that RFCs 7[5]34 & 7[5]35 have been published, how do ISC see the >> future >> of the seemingly ever-expanding built-in empty zone list in BIND? >> >> One possibility that seems plausible to me is to add EMPTY.AS112.ARPA >> to the list now, and remove existing entries if and when the corresponding >> names in the public DNS acquire DNAMEs pointing to that (hopefully ones >> with large TTLs). >> > > Adding empty.as112.arpa to the list seems like a good idea, but removing > the existing empty zones does not -- they also prevent leaking internal > queries, which is both more noise for the root/IANA/AS112 infrastructure to > sink and a potential privacy concern. > > There's also the minor benefit of fast responses from local resolvers, > which still matters for determinism in the initial query. From where I > sit, the nearest blackhole.as112.arpa is 90+ms and an ocean away (v4 or > v6), and the existing AS112 nodes aren't much better. > > What would be gained by shrinking the number of empty zones? The only > thing that comes to mind is that it'd make life marginally easier for those > who run cache hierarchies and override some of those zones at the top > level, but there's already an option for that and I'm definitely grasping > at straws here... Yup. One of the advantages to the new style AS112 / DNAME solution is that you can easily add *and* remove zones from AS112. This means that we can more easily add things that may need to be removed in the future -- but I don't think any of the existing things fall into this category. I'm not actually suggesting this, but imagine delegating .belkin to AS112 - at the moment it is all noise at the root, one day it may be real. Using old style AS112 you cannot do this, with the DNAME solution perhaps you could W > > -Rob > ___ > 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ 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: Future of BIND's built-in empty zone list
In message , Warren Kumari writes: > On Thursday, May 14, 2015, Rob Foehl wrote: > > > On Thu, 14 May 2015, Chris Thompson wrote: > > > > Now that RFCs 7[5]34 & 7[5]35 have been published, how do ISC see the > >> future > >> of the seemingly ever-expanding built-in empty zone list in BIND? > >> > >> One possibility that seems plausible to me is to add EMPTY.AS112.ARPA > >> to the list now, and remove existing entries if and when the correspondin > g > >> names in the public DNS acquire DNAMEs pointing to that (hopefully ones > >> with large TTLs). > >> > > > > Adding empty.as112.arpa to the list seems like a good idea, but removing > > the existing empty zones does not -- they also prevent leaking internal > > queries, which is both more noise for the root/IANA/AS112 infrastructure t > o > > sink and a potential privacy concern. > > > > There's also the minor benefit of fast responses from local resolvers, > > which still matters for determinism in the initial query. From where I > > sit, the nearest blackhole.as112.arpa is 90+ms and an ocean away (v4 or > > v6), and the existing AS112 nodes aren't much better. > > > > What would be gained by shrinking the number of empty zones? The only > > thing that comes to mind is that it'd make life marginally easier for thos > e > > who run cache hierarchies and override some of those zones at the top > > level, but there's already an option for that and I'm definitely grasping > > at straws here... > > > Yup. > > One of the advantages to the new style AS112 / DNAME solution is that you > can easily add *and* remove zones from AS112. This means that we can more > easily add things that may need to be removed in the future -- but I don't > think any of the existing things fall into this category. > > I'm not actually suggesting this, but imagine delegating .belkin to AS112 - > at the moment it is all noise at the root, one day it may be real. Using > old style AS112 you cannot do this, with the DNAME solution perhaps you > could > > W When IANA and ARIN finally gets around to doing 64.100.IN-ADDR.ARPA et al., which has been waiting over a year for the of DNSOP to write up the last call of draft-ietf-dnsop-rfc6598-rfc6303 to be written up, it should be done similar to this with a insecure delegation to 64.100.IN-ADDR.ARPA, to allow the ISP's using this range and others to server their own instances of 64.100.IN-ADDR.ARPA without DNSSEC validation failures, and a DNAME to the AS112 traffic sink for the leaked traffic. 64.100.IN-ADDR.ARPA SOA ... 64.100.IN-ADDR.ARPA NS ... 64.100.IN-ADDR.ARPA NS ... 64.100.IN-ADDR.ARPA DNAME EMPTY.AS112.ARPA Note: there are no DNSKEY records. This is deliberate. Recursive nameservers will just have the traditional locally served empty zone by default. 64.100.IN-ADDR.ARPA SOA ... 64.100.IN-ADDR.ARPA NS ... Mark > > -Rob > > ___ > > 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 > > > > > -- > I don't think the execution is relevant when it was obviously a bad idea in > the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. >---maf > > --f46d043c80bc062bee0516210c9a > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > On Thursday, May 14, 2015, Rob Foehl < 7B%7D,'cvml','r...@loonybin.net');" target=3D"_blank">rwf@lo= > onybin.net> wrote: gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 14 May = > 2015, Chris Thompson wrote: > > x #ccc solid;padding-left:1ex"> > Now that RFCs 7[5]34 & 7[5]35 have been published, how do ISC see the f= > uture > of the seemingly ever-expanding built-in empty zone list in BIND? > > One possibility that seems plausible to me is to add EMPTY.AS112.ARPA > to the list now, and remove existing entries if and when the corresponding<= > br> > names in the public DNS acquire DNAMEs pointing to that (hopefully ones > with large TTLs). > > > Adding empty.as112.arpa to the list seems like a good idea, but removing th= > e existing empty zones does not -- they also prevent leaking internal queri= > es, which is both more noise for the root/IANA/AS112 infrastructure to sink= > and a potential privacy concern. > > There's also the minor benefit of fast responses from local resolvers, = > which still matters for determinism in the initial query.=C2=A0 From where = > I sit, the nearest blackhole.as112.arpa is 90+ms and an ocean away (v4 or v= > 6), and the existing AS112 nodes aren't much better. > > What would be gained by shrinking the number of empty zones?=C2=A0 The only= > thing that comes to mind is that it'd make life marginally easier for = > those who run cache hierarchies and override some o
