<html xmlns="http://www.w3.org/1999/xhtml" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office"><head><!--[if gte mso 9]><xml><o:OfficeDocumentSettings><o:AllowPNG/><o:PixelsPerInch>96</o:PixelsPerInch></o:OfficeDocumentSettings></xml><![endif]--></head><body>
Hello blind users do you mind pissing the fuck off u dirty bastard<div><br></div><div>Many thanks,</div><div>Cloudflare Security<br><br><br><a href="https://overview.mail.yahoo.com/?.src=iOS">Sent from Yahoo Mail for iPhone</a><br><br><p class="yahoo-quoted-begin" style="font-size: 15px; color: #715FFA; padding-top: 15px; margin-top: 0">On Sunday, July 14, 2019, 1:00 pm, bind-users-request@lists.isc.org wrote:</p><blockquote class="iosymail"><div dir="ltr">Send bind-users mailing list submissions to<br></div><div dir="ltr">    <a ymailto="mailto:bind-users@lists.isc.org" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br></div><div dir="ltr"><br></div><div dir="ltr">To subscribe or unsubscribe via the World Wide Web, visit<br></div><div dir="ltr">    <a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br></div><div dir="ltr">or, via email, send a message with subject or body 'help' to<br></div><div dir="ltr">    <a ymailto="mailto:bind-users-request@lists.isc.org" href="mailto:bind-users-request@lists.isc.org">bind-users-request@lists.isc.org</a><br></div><div dir="ltr"><br></div><div dir="ltr">You can reach the person managing the list at<br></div><div dir="ltr">    <a ymailto="mailto:bind-users-owner@lists.isc.org" href="mailto:bind-users-owner@lists.isc.org">bind-users-owner@lists.isc.org</a><br></div><div dir="ltr"><br></div><div dir="ltr">When replying, please edit your Subject line so it is more specific<br></div><div dir="ltr">than "Re: Contents of bind-users digest..."<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">Today's Topics:<br></div><div dir="ltr"><br></div><div dir="ltr">   1. Re: static stub zone not working as expected (Jay Ford)<br></div><div dir="ltr">   2. Re: rndc - sync before reload? (Anand Buddhdev)<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">----------------------------------------------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 1<br></div><div dir="ltr">Date: Sat, 13 Jul 2019 10:18:33 -0500 (CDT)<br></div><div dir="ltr">From: Jay Ford <<a ymailto="mailto:jnford@uiowa.net" href="mailto:jnford@uiowa.net">jnford@uiowa.net</a>><br></div><div dir="ltr">To: Mark Andrews <<a ymailto="mailto:marka@isc.org" href="mailto:marka@isc.org">marka@isc.org</a>><br></div><div dir="ltr">Cc: bind-users <<a ymailto="mailto:bind-users@lists.isc.org" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>><br></div><div dir="ltr">Subject: Re: static stub zone not working as expected<br></div><div dir="ltr">Message-ID: <<a ymailto="mailto:alpine.DEB.2.20.1907131010590.623@headset.its.uiowa.edu" href="mailto:alpine.DEB.2.20.1907131010590.623@headset.its.uiowa.edu">alpine.DEB.2.20.1907131010590.623@headset.its.uiowa.edu</a>><br></div><div dir="ltr">Content-Type: text/plain; charset="iso8859-7"; Format="flowed"<br></div><div dir="ltr"><br></div><div dir="ltr">I'm still confused about why named looks further up the tree than<br></div><div dir="ltr">c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which it holds authoritatively via<br></div><div dir="ltr">master/slave zone type.  That seems like incorrect behavior.<br></div><div dir="ltr"><br></div><div dir="ltr">Is this something I can fix or work around?<br></div><div dir="ltr"><br></div><div dir="ltr">__________________________________________________________________________<br></div><div dir="ltr">Jay Ford <<a ymailto="mailto:jnford@uiowa.net" href="mailto:jnford@uiowa.net">jnford@uiowa.net</a>>, Network Engineering, University of Iowa<br></div><div dir="ltr"><br></div><div dir="ltr">On Sat, 13 Jul 2019, Mark Andrews wrote:<br></div><div dir="ltr">> 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.<br></div><div dir="ltr">><br></div><div dir="ltr">> 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.<br></div><div dir="ltr">> -- <br></div><div dir="ltr">> Mark Andrews<br></div><div dir="ltr">><br></div><div dir="ltr">>> On 13 Jul 2019, at 00:42, Jay Ford <<a ymailto="mailto:jnford@uiowa.net" href="mailto:jnford@uiowa.net">jnford@uiowa.net</a>> wrote:<br></div><div dir="ltr">>><br></div><div dir="ltr">>> On Fri, 12 Jul 2019, Mark Andrews wrote:<br></div><div dir="ltr">>>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews <<a ymailto="mailto:marka@isc.org" href="mailto:marka@isc.org">marka@isc.org</a>> wrote:<br></div><div dir="ltr">>>>><br></div><div dir="ltr">>>>>> On 12 Jul 2019, at 11:12 am, Jay Ford <<a ymailto="mailto:jnford@uiowa.net" href="mailto:jnford@uiowa.net">jnford@uiowa.net</a>> wrote:<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> 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:<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>>  validate-except { "f.ip6.arpa"; };<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> but alas, no.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> 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.<br></div><div dir="ltr">>>>>><br></div><div dir="ltr">>>>>> In the ULA space it doesn't seem trivial to own the top zone (ip6.arpa) without breaking stuff.  Any suggestions for that case?<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> ULA space it trivial to own.  D.F.IP6.ARPA is what you use if you have multiple ULA prefixes.<br></div><div dir="ltr">>>> 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<br></div><div dir="ltr">>>> which matches the ULA prefix used in the system tests (fd92:7065:b8e::/48).<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> This is no different to using 10.in-addr.arpa, 168.192.in-addr.arpa or one of 16.172.in-addr.arpa<br></div><div dir="ltr">>>> though 31.172.in-addr.arpa for RFC 1918 space.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> If fc00::/8 is ever used then you would also have C.F.IP6.ARPA.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> Named creates the D.F.IP6.ARPA zone automatically if you don?t create it when the view is<br></div><div dir="ltr">>>> configured for recursion.  This is done to stop reverse lookups leaking onto the internet<br></div><div dir="ltr">>>> as a whole.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> % dig soa d.f.ip6.arpa<br></div><div dir="ltr">>>> ;; BADCOOKIE, retrying.<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> ; <<>> DiG 9.15.1 <<>> soa d.f.ip6.arpa<br></div><div dir="ltr">>>> ;; global options: +cmd<br></div><div dir="ltr">>>> ;; Got answer:<br></div><div dir="ltr">>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23519<br></div><div dir="ltr">>>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> ;; OPT PSEUDOSECTION:<br></div><div dir="ltr">>>> ; EDNS: version: 0, flags:; udp: 4096<br></div><div dir="ltr">>>> ; COOKIE: aa8a24a1cce6c010b9d3a1b75d28009bb013cb0a2f58a961 (good)<br></div><div dir="ltr">>>> ;; QUESTION SECTION:<br></div><div dir="ltr">>>> ;d.f.ip6.arpa.            IN    SOA<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> ;; ANSWER SECTION:<br></div><div dir="ltr">>>> D.F.IP6.ARPA.        86400    IN    SOA    D.F.IP6.ARPA. . <a dir="ltr" href="tel:0%2028800%207200" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="16">0 28800 7200</a> 604800 86400<br></div><div dir="ltr">>>><br></div><div dir="ltr">>>> ;; Query time: 0 msec<br></div><div dir="ltr">>>> ;; SERVER: 127.0.0.1#53(127.0.0.1)<br></div><div dir="ltr">>>> ;; WHEN: Fri Jul 12 13:38:03 AEST 2019<br></div><div dir="ltr">>>> ;; MSG SIZE  rcvd: 116<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Yep, that's what I thought.  I have master/slave for the zone corresponding<br></div><div dir="ltr">>> to my ULA /48 (c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa), which is solid including<br></div><div dir="ltr">>> zones under it also handled as master/slave, but not for zones which are<br></div><div dir="ltr">>> delegated via NS records to other servers (not master/slave), such as<br></div><div dir="ltr">>> d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which usually resolves like this:<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   % 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<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   ; <<>> 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<br></div><div dir="ltr">>>   ;; global options: +cmd<br></div><div dir="ltr">>>   ;; Got answer:<br></div><div dir="ltr">>>   ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23886<br></div><div dir="ltr">>>   ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   ;; OPT PSEUDOSECTION:<br></div><div dir="ltr">>>   ; EDNS: version: 0, flags:; udp: 4096<br></div><div dir="ltr">>>   ;; QUESTION SECTION:<br></div><div dir="ltr">>>   ;d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. IN NS<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   ;; ANSWER SECTION:<br></div><div dir="ltr">>>   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.<br></div><div dir="ltr">>>   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.<br></div><div dir="ltr">>>   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.<br></div><div dir="ltr">>>   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.<br></div><div dir="ltr">>>   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.<br></div><div dir="ltr">>>   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.<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   ;; Query time: 2 msec<br></div><div dir="ltr">>>   ;; SERVER: fd9a:2c75:7d0c:5::e#53(fd9a:2c75:7d0c:5::e)<br></div><div dir="ltr">>>   ;; WHEN: Fri Jul 12 09:19:30 CDT 2019<br></div><div dir="ltr">>>   ;; MSG SIZE  rcvd: 215<br></div><div dir="ltr">>><br></div><div dir="ltr">>> but sometimes fails like this:<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   % 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<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   ; <<>> 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<br></div><div dir="ltr">>>   ;; global options: +cmd<br></div><div dir="ltr">>>   ;; Got answer:<br></div><div dir="ltr">>>   ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 20175<br></div><div dir="ltr">>>   ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   ;; OPT PSEUDOSECTION:<br></div><div dir="ltr">>>   ; EDNS: version: 0, flags:; udp: 4096<br></div><div dir="ltr">>>   ;; QUESTION SECTION:<br></div><div dir="ltr">>>   ;d.0.8.6.c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. IN NS<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   ;; AUTHORITY SECTION:<br></div><div dir="ltr">>>   ip6.arpa.  3009  IN  SOA  b.ip6-servers.arpa. nstld.iana.org. <a dir="ltr" href="tel:2019024499" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="30">2019024499</a> <a dir="ltr" href="tel:1800%20900%20604800" x-apple-data-detectors="true" x-apple-data-detectors-type="telephone" x-apple-data-detectors-result="31">1800 900 604800</a> 3600<br></div><div dir="ltr">>><br></div><div dir="ltr">>>   ;; Query time: 0 msec<br></div><div dir="ltr">>>   ;; SERVER: fd9a:2c75:7d0c:5::a#53(fd9a:2c75:7d0c:5::a)<br></div><div dir="ltr">>>   ;; WHEN: Fri Jul 12 09:19:25 CDT 2019<br></div><div dir="ltr">>>   ;; MSG SIZE  rcvd: 145<br></div><div dir="ltr">>><br></div><div dir="ltr">>> Those 2 servers (& others) are configured identically regarding the zones in<br></div><div dir="ltr">>> question, but some of them sometimes fail this way despite being<br></div><div dir="ltr">>> authoritative for c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa. An "rndc flushtree<br></div><div dir="ltr">>> ip6.arpa" will fix it for a while.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> I do very similar stuff with zones for IPv4 RFC1918 space with no trouble.  I<br></div><div dir="ltr">>> had noticed the authenticated behavior for f.ip6.arpa differing from the<br></div><div dir="ltr">>> behavior for 10.in-addr.arpa & friends.  Thanks for poking at IANA about<br></div><div dir="ltr">>> that.  As I mentioned earlier, my use of validate-except { "f.ip6.arpa"; };<br></div><div dir="ltr">>> to work around that failed to help.  Can you explain why?<br></div><div dir="ltr">>><br></div><div dir="ltr">>> I might be hijacking this thread, but it seemed possible that my issue & that<br></div><div dir="ltr">>> of the original poster could have a common root cause.  I can start a<br></div><div dir="ltr">>> different thread on the list or pursue it as a BIND bug if you think that's<br></div><div dir="ltr">>> more appropriate.<br></div><div dir="ltr">>><br></div><div dir="ltr">>> __________________________________________________________________________<br></div><div dir="ltr">>> Jay Ford <<a ymailto="mailto:jnford@uiowa.net" href="mailto:jnford@uiowa.net">jnford@uiowa.net</a>>, Network Engineering, University of Iowa<br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Message: 2<br></div><div dir="ltr">Date: Sun, 14 Jul 2019 00:48:14 +0300<br></div><div dir="ltr">From: Anand Buddhdev <<a ymailto="mailto:anandb@ripe.net" href="mailto:anandb@ripe.net">anandb@ripe.net</a>><br></div><div dir="ltr">To: John Thurston <<a ymailto="mailto:john.thurston@alaska.gov" href="mailto:john.thurston@alaska.gov">john.thurston@alaska.gov</a>>, <a ymailto="mailto:bind-users@lists.isc.org" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br></div><div dir="ltr">Subject: Re: rndc - sync before reload?<br></div><div dir="ltr">Message-ID: <<a ymailto="mailto:8598f31c-5d21-5bfa-a70b-350f081aad29@ripe.net" href="mailto:8598f31c-5d21-5bfa-a70b-350f081aad29@ripe.net">8598f31c-5d21-5bfa-a70b-350f081aad29@ripe.net</a>><br></div><div dir="ltr">Content-Type: text/plain; charset=utf-8<br></div><div dir="ltr"><br></div><div dir="ltr">On 10/07/2019 20:08, John Thurston wrote:<br></div><div dir="ltr"><br></div><div dir="ltr">Hi John,<br></div><div dir="ltr"><br></div><div dir="ltr">> On a server with both static and dynamic zones, is there any reason to<br></div><div dir="ltr">> perform an:<br></div><div dir="ltr">> ? rndc sync<br></div><div dir="ltr">> prior to issuing an:<br></div><div dir="ltr">> ? rndc reload<br></div><div dir="ltr"><br></div><div dir="ltr">No, there is no need for a sync before reload.<br></div><div dir="ltr"><br></div><div dir="ltr">Regards,<br></div><div dir="ltr">Anand<br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">Subject: Digest Footer<br></div><div dir="ltr"><br></div><div dir="ltr">_______________________________________________<br></div><div dir="ltr">bind-users mailing list<br></div><div dir="ltr"><a ymailto="mailto:bind-users@lists.isc.org" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a><br></div><div dir="ltr"><a href="https://lists.isc.org/mailman/listinfo/bind-users" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">------------------------------<br></div><div dir="ltr"><br></div><div dir="ltr">End of bind-users Digest, Vol 3234, Issue 1<br></div><div dir="ltr">*******************************************<br></div><blockquote></blockquote></blockquote></div>
</body></html>