[IANA #1147230] Re: static stub zone not working as expected

Mark Andrews marka at isc.org
Wed Jul 24 13:18:17 UTC 2019


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-questions at 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, marka at isc.org wrote:
>> 
>> 
>>> On 14 Jul 2019, at 1:18 am, Jay Ford <jnford at 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 <jnford at 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 <jnford at uiowa.net> wrote:
>>>>> 
>>>>> On Fri, 12 Jul 2019, Mark Andrews wrote:
>>>>>>> On 12 Jul 2019, at 1:00 pm, Mark Andrews <marka at isc.org> wrote:
>>>>>>> 
>>>>>>>> On 12 Jul 2019, at 11:12 am, Jay Ford <jnford at 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 <jnford at uiowa.net>, Network Engineering, University of
>>>>> Iowa
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org



More information about the bind-users mailing list