I meant d.f.ip6.arpa rather than f.d.in-addr.arpa.
> On 24 Jul 2019, at 11:18 pm, Mark Andrews <ma...@isc.org> wrote:
>
> There is f.d.in-addr.arpa which is what this ticket is about and
> ipv4only.arpa which Stuart Cheshire is writing a update for and for which
> there is a seperate ticket. Both are DNSSEC related. Both cause operational
> problems. Both involve having unsigned zones for the relevant names.
>
> For f.d.in-addr.arpa there are clear instructions to break the chain of trust.
>
> For ipv4only.arpa you need to understand the RFC to know that ipv4only.arpa
> should be unsigned. Stuart’s draft just makes that clearer.
>
> Please don’t confuse the two issues.
>
> Mark
>
>> On 24 Jul 2019, at 10:24 pm, Michelle Cotton via RT
>> <iana-questi...@iana.org> wrote:
>>
>> Hello Mark,
>>
>> Thank you for your message.
>>
>> We are in discussion with IESG members on this matter. When this was being
>> discussed last year with IESG members, we were advised not to proceed at
>> that time as there was a document that was going to be written to document
>> the instructions.
>> We are following up to see what the status is and will keep you informed.
>>
>> Thank you,
>>
>> Michelle Cotton
>>
>>
>> On Sun Jul 14 21:31:52 2019, ma...@isc.org wrote:
>>>
>>>
>>>> On 14 Jul 2019, at 1:18 am, Jay Ford <jnf...@uiowa.net> wrote:
>>>>
>>>> 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.
>>>
>>> The cache doesn’t know about zones. The lookup just make a query of
>>> the cache for the name and also asks for potential covering NSEC
>>> records
>>> to be returned if it is not found. In this case it finds a covering
>>> NSEC
>>> record.
>>>
>>> 0.c.2.ip6.arpa. 3012 IN NSEC ip6.arpa. NS DS RRSIG
>>> NSEC
>>>
>>> d.f.ip6.arpa lies between 0.c.2.ip6.arpa and ip6.arpa. Now if there
>>> was
>>> the requested break in the chain of trust existed that was requested
>>> to be
>>> added in RFC 6303 it would find.
>>>
>>> d.f.ip6.arpa. 3600 IN NSEC ip6.arpa. NS RRSIG NSEC
>>>
>>> Which says d.f.ip6.arpa is a delegation point so I don’t know anything
>>> about
>>> names ending in d.f.ip6.arpa but there are no names in ip6.arpa
>>> between
>>> d.f.ip6.arpa and ip6.arpa. Named won’t synthesis negative responses
>>> for ULA
>>> reverse names from that NSEC record.
>>>
>>>> Is this something I can fix or work around?
>>>
>>> You can turn off synthesis "synth-from-dnssec no;”
>>>
>>>> __________________________________________________________________________
>>>> 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
>>
>
> --
> 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
--
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
