Hello blind users do you mind pissing the fuck off u dirty bastard Many thanks,Cloudflare Security
Sent from Yahoo Mail for iPhone On Sunday, July 14, 2019, 1:00 pm, bind-users-requ...@lists.isc.org wrote: Send bind-users mailing list submissions to bind-users@lists.isc.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/bind-users or, via email, send a message with subject or body 'help' to bind-users-requ...@lists.isc.org You can reach the person managing the list at bind-users-ow...@lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of bind-users digest..." Today's Topics: 1. Re: static stub zone not working as expected (Jay Ford) 2. Re: rndc - sync before reload? (Anand Buddhdev) ---------------------------------------------------------------------- Message: 1 Date: Sat, 13 Jul 2019 10:18:33 -0500 (CDT) From: Jay Ford <jnf...@uiowa.net> To: Mark Andrews <ma...@isc.org> Cc: bind-users <bind-users@lists.isc.org> Subject: Re: static stub zone not working as expected Message-ID: <alpine.deb.2.20.1907131010590....@headset.its.uiowa.edu> Content-Type: text/plain; charset="iso8859-7"; Format="flowed" I'm still confused about why named looks further up the tree than c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which it holds authoritatively via master/slave zone type. That seems like incorrect behavior. Is this something I can fix or work around? __________________________________________________________________________ Jay Ford <jnf...@uiowa.net>, Network Engineering, University of Iowa On Sat, 13 Jul 2019, Mark Andrews wrote: > I suspect this will be negative response synthesis. The cache has learnt that > d.f.ip6.arpa doesn?t exist in ip6.arpa and when the name in question is > looked up the covering NSEC is returned which covers all of ULA space. > > If I?m right querying for DS d.f.ip6.arpa will load the cache appropriately > to allow this to be triggered. One then needs to trigger a lookup for a name > which finds the covering NSEC in the search back through the cache. Named > skips some responses in the search depending on the content but aborts it on > others content. > -- > Mark Andrews > >> On 13 Jul 2019, at 00:42, Jay Ford <jnf...@uiowa.net> wrote: >> >> On Fri, 12 Jul 2019, Mark Andrews wrote: >>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews <ma...@isc.org> wrote: >>>> >>>>> On 12 Jul 2019, at 11:12 am, Jay Ford <jnf...@uiowa.net> wrote: >>>>> >>>>> I have a similar problem with zones for IPv6 ULA space. I'm running BIND >>>>> 9.14.3. I had hoped that validate-except would do the trick, such as: >>>>> >>>>> validate-except { "f.ip6.arpa"; }; >>>>> >>>>> but alas, no. >>>>> >>>>> Extra puzzling so far is that the behavior is time-variable: delegated >>>>> zones will resolve most of the time, but then fail (NXDOMAIN) for a while. >>>>> >>>>> In the ULA space it doesn't seem trivial to own the top zone (ip6.arpa) >>>>> without breaking stuff. Any suggestions for that case? >>> >>> ULA space it trivial to own. D.F.IP6.ARPA is what you use if you have >>> multiple ULA prefixes. >>> If you have a single ULA prefix in use then just use that. e.g. >>> e.8.b.0.5.6.0.7.2.9.d.f.ip6.arpa >>> which matches the ULA prefix used in the system tests (fd92:7065:b8e::/48). >>> >>> This is no different to using 10.in-addr.arpa, 168.192.in-addr.arpa or one >>> of 16.172.in-addr.arpa >>> though 31.172.in-addr.arpa for RFC 1918 space. >>> >>> If fc00::/8 is ever used then you would also have C.F.IP6.ARPA. >>> >>> Named creates the D.F.IP6.ARPA zone automatically if you don?t create it >>> when the view is >>> configured for recursion. This is done to stop reverse lookups leaking >>> onto the internet >>> as a whole. >>> >>> % dig soa d.f.ip6.arpa >>> ;; BADCOOKIE, retrying. >>> >>> ; <<>> DiG 9.15.1 <<>> soa d.f.ip6.arpa >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23519 >>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ; COOKIE: aa8a24a1cce6c010b9d3a1b75d28009bb013cb0a2f58a961 (good) >>> ;; QUESTION SECTION: >>> ;d.f.ip6.arpa. IN SOA >>> >>> ;; ANSWER SECTION: >>> D.F.IP6.ARPA. 86400 IN SOA D.F.IP6.ARPA. . 0 28800 7200 >>> 604800 86400 >>> >>> ;; Query time: 0 msec >>> ;; SERVER: 127.0.0.1#53(127.0.0.1) >>> ;; WHEN: Fri Jul 12 13:38:03 AEST 2019 >>> ;; MSG SIZE rcvd: 116 >> >> Yep, that's what I thought. I have master/slave for the zone corresponding >> to my ULA /48 (c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa), which is solid including >> zones under it also handled as master/slave, but not for zones which are >> delegated via NS records to other servers (not master/slave), such as >> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which usually resolves like this: >> >> % dig -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu >> >> ; <<>> DiG 9.10.3-P4-Debian <<>> -t ns >>d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-itf.uiowa.edu >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23886 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. IN NS >> >> ;; ANSWER SECTION: >> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc1.iowa.uiowa.edu. >> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc4.iowa.uiowa.edu. >> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc3.iowa.uiowa.edu. >> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc5.iowa.uiowa.edu. >> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc2.iowa.uiowa.edu. >> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. 3600 IN NS iowadc6.iowa.uiowa.edu. >> >> ;; Query time: 2 msec >> ;; SERVER: fd9a:2c75:7d0c:5::e#53(fd9a:2c75:7d0c:5::e) >> ;; WHEN: Fri Jul 12 09:19:30 CDT 2019 >> ;; MSG SIZE rcvd: 215 >> >> but sometimes fails like this: >> >> % dig -t ns d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-cb.uiowa.edu >> >> ; <<>> DiG 9.10.3-P4-Debian <<>> -t ns >>d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa @dns-cb.uiowa.edu >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20175 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. IN NS >> >> ;; AUTHORITY SECTION: >> ip6.arpa. 3009 IN SOA b.ip6-servers.arpa. nstld.iana.org. 2019024499 >>1800 900 604800 3600 >> >> ;; Query time: 0 msec >> ;; SERVER: fd9a:2c75:7d0c:5::a#53(fd9a:2c75:7d0c:5::a) >> ;; WHEN: Fri Jul 12 09:19:25 CDT 2019 >> ;; MSG SIZE rcvd: 145 >> >> Those 2 servers (& others) are configured identically regarding the zones in >> question, but some of them sometimes fail this way despite being >> authoritative for c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. An "rndc flushtree >> ip6.arpa" will fix it for a while. >> >> I do very similar stuff with zones for IPv4 RFC1918 space with no trouble. I >> had noticed the authenticated behavior for f.ip6.arpa differing from the >> behavior for 10.in-addr.arpa & friends. Thanks for poking at IANA about >> that. As I mentioned earlier, my use of validate-except { "f.ip6.arpa"; }; >> to work around that failed to help. Can you explain why? >> >> I might be hijacking this thread, but it seemed possible that my issue & that >> of the original poster could have a common root cause. I can start a >> different thread on the list or pursue it as a BIND bug if you think that's >> more appropriate. >> >> __________________________________________________________________________ >> Jay Ford <jnf...@uiowa.net>, Network Engineering, University of Iowa ------------------------------ Message: 2 Date: Sun, 14 Jul 2019 00:48:14 +0300 From: Anand Buddhdev <ana...@ripe.net> To: John Thurston <john.thurs...@alaska.gov>, bind-users@lists.isc.org Subject: Re: rndc - sync before reload? Message-ID: <8598f31c-5d21-5bfa-a70b-350f081aa...@ripe.net> Content-Type: text/plain; charset=utf-8 On 10/07/2019 20:08, John Thurston wrote: Hi John, > On a server with both static and dynamic zones, is there any reason to > perform an: > ? rndc sync > prior to issuing an: > ? rndc reload No, there is no need for a sync before reload. Regards, Anand ------------------------------ Subject: Digest Footer _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ------------------------------ End of bind-users Digest, Vol 3234, Issue 1 *******************************************
_______________________________________________ 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
