Opened 7 years ago

Closed 7 years ago

#2503 closed defect (fixed)

Problem in inmem NSEC3 denial of existence handling

Reported by: jelte Owned by: muks
Priority: medium Milestone: Sprint-20121218
Component: data source Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: Low
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 3 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

Granted, my zone is somewhat artificial; is only has a few records, but more importantly, it only has 1 name.

So it also only has 1 nsec3 record, and that apparently causes some problems.

the zone is ok.ok.ok.ok.nsec3.tjeb.nl, and transfering it gives the following data:

ok.ok.ok.ok.nsec3.tjeb.nl.	600	IN	SOA	ns2.tjeb.nl. tjeb.tjeb.nl. 2005080901 28800 7200 604800 18000
ok.ok.ok.ok.nsec3.tjeb.nl.	600	IN	A	178.18.82.80
ok.ok.ok.ok.nsec3.tjeb.nl.	3600	IN	DNSKEY	256 3 7 AwEAAcVaFlRylmfW8CiGTWpSvom6cxuqsEJeteXR+YrCrCuriTu8P6ou/43/db9ooybB62JuREvoosmjtf0i7tZIAUFh87c1+3JTdra+W4WcCNYNEZW1I41J/OjMEOwKVxH2V1GgZGThrNgvZj7xqeusG2fP0DScDO3/gBr9PJGi9JTD ;{id = 56765 (zsk), size = 1024b}
ok.ok.ok.ok.nsec3.tjeb.nl.	600	IN	NS	ns2.tjeb.nl.
ok.ok.ok.ok.nsec3.tjeb.nl.	3600	IN	NSEC3PARAM	1 0 5 beef 
ok.ok.ok.ok.nsec3.tjeb.nl.	600	IN	RRSIG	SOA 7 7 600 20150101000000 20110520094818 56765 ok.ok.ok.ok.nsec3.tjeb.nl. S7kx8CgkvczbZzJRzG9JiUa5JdEwPdJCniVPcCqUfQVbF6Lfe/iPbLBBguWZJDcPNCm1txvzz8tuYf0z2dziAxQefWPnh7Y1ABZSft1X19L9kz6QGcsxcAvw039t3aX8fyTmiAU1nUthj5u6UdUqGVdxla4RdpipfN2zXNAJ64E=
ok.ok.ok.ok.nsec3.tjeb.nl.	600	IN	RRSIG	A 7 7 600 20150101000000 20110520094818 56765 ok.ok.ok.ok.nsec3.tjeb.nl. TrBhFbKGkp427sPnhtT9andQlnfKjY9DE8U++rdbXfY30aKssN/Mb/M0HK+RBlBDUsL9YbkG6XU345zkIWBIqxHBf0wJuVd3vYggDikyNhrtGtS0sJCHKrX/Im5gMVWeN6m47Mp8LWK2yFJeOdGEn5BLfyhnPpYO4/te52FyboI=
ok.ok.ok.ok.nsec3.tjeb.nl.	600	IN	RRSIG	NS 7 7 600 20150101000000 20110520094818 56765 ok.ok.ok.ok.nsec3.tjeb.nl. YcTwEpjPxxDyM+d0hG3pfYavfbOKFxUqY0jyZ3dcns5uEelmgi/7D5yGbE8Dq0OzWFyR5sjBf4+7WGqNJwY+fSmbXOzaqfmVMtSC3R068GDd6NrXs4WfrjfYOeajwCuseB3L89fofy/7EfJbcQVA7JUEBjPBH2RXu8dgXNuLghk=
ok.ok.ok.ok.nsec3.tjeb.nl.	3600	IN	RRSIG	DNSKEY 7 7 3600 20150101000000 20110520094818 56765 ok.ok.ok.ok.nsec3.tjeb.nl. ZcJ1DpuiJfisbYu/24q1EC1IwP6j0TDPcxFMNHUeU7m0N0lAgk2S0tM//qhMPkBygN3VgHa9yhnxhIvct3amBxTZh9VcFz66vMmzCuEpWPB3aHRPIhltUGDNGi8H6UtUmX/RKuX23WloaG9Wnh8FBX0RJKkW6R3JLgWD4EJkF78=
ok.ok.ok.ok.nsec3.tjeb.nl.	3600	IN	RRSIG	NSEC3PARAM 7 7 3600 20150101000000 20110520094818 56765 ok.ok.ok.ok.nsec3.tjeb.nl. QhxpZzlG8/NUvZXzgGOzKeJCir+58m/rlZn3IARO54XXtzfd6fNSJHT+SMpD2PdzonblqhUqbqxucQNpjuVxIocIUIAcCj2F0K1oxxknIFr/j+XIaB4plsrRH7yPUYnym6xAUMcQRxob5FjYYc2vXjHRHF8M0qeEjyrNP8m7keU=
tv3jp54nve7jfnhvba54uc031shjv2d3.ok.ok.ok.ok.nsec3.tjeb.nl.	18000	IN	NSEC3	1 0 5 beef  tv3jp54nve7jfnhvba54uc031shjv2d3 A NS SOA RRSIG DNSKEY NSEC3PARAM 
tv3jp54nve7jfnhvba54uc031shjv2d3.ok.ok.ok.ok.nsec3.tjeb.nl.	18000	IN	RRSIG	NSEC3 7 8 18000 20150101000000 20110520094818 56765 ok.ok.ok.ok.nsec3.tjeb.nl. p7WlTLC3CatciKMkDNvXeKCXCNHstR2c/Mu62EXBHL1jrNuSx1S8crOGYFzELNtSA7paTO6/Uc8U7xRdf3IUb517obQCEVrpPyp4YTxlg8YwgAe5azklW11aYkW4E/nqsXUQnWieiuEWwTPYdVZLnrnu7NxH+IA+uGHHP689xPY=
ok.ok.ok.ok.nsec3.tjeb.nl.	600	IN	SOA	ns2.tjeb.nl. tjeb.tjeb.nl. 2005080901 28800 7200 604800 18000

Normal digs/drills for this data work, but for an NXDOMAIN or NOERROR/NODATA, it returns SERVFAIL.

The output log shows:

2012-11-22 22:25:00.912 ERROR [b10-auth.auth] AUTH_PROCESS_FAIL message processing failure: findNSEC3 attempt but zone has no NSEC3 RRs: ok.ok.ok.ok.nsec3.tjeb.nl./IN

note, this exception text occurs twice, I've confirmed it is the second case (trying to find origin node); loading itself works fine:

2012-11-22 22:32:12.642 DEBUG [b10-auth.datasrc_memory] DATASRC_MEMORY_MEM_LOAD loading zone 'ok.ok.ok.ok.nsec3.tjeb.nl.' from file 'ok.ok.ok.ok.nsec3.tjeb.nl.'
2012-11-22 22:32:12.643 DEBUG [b10-auth.datasrc_memory] DATASRC_MEMORY_MEM_ADD_RRSET adding RRset 'ok.ok.ok.ok.nsec3.tjeb.nl./A' into zone 'ok.ok.ok.ok.nsec3.tjeb.nl.'
2012-11-22 22:32:12.643 DEBUG [b10-auth.datasrc_memory] DATASRC_MEMORY_MEM_ADD_RRSET adding RRset 'ok.ok.ok.ok.nsec3.tjeb.nl./NS' into zone 'ok.ok.ok.ok.nsec3.tjeb.nl.'
2012-11-22 22:32:12.643 DEBUG [b10-auth.datasrc_memory] DATASRC_MEMORY_MEM_ADD_RRSET adding RRset 'ok.ok.ok.ok.nsec3.tjeb.nl./SOA' into zone 'ok.ok.ok.ok.nsec3.tjeb.nl.'
2012-11-22 22:32:12.643 DEBUG [b10-auth.datasrc_memory] DATASRC_MEMORY_MEM_ADD_RRSET adding RRset 'ok.ok.ok.ok.nsec3.tjeb.nl./DNSKEY' into zone 'ok.ok.ok.ok.nsec3.tjeb.nl.'
2012-11-22 22:32:12.643 DEBUG [b10-auth.datasrc_memory] DATASRC_MEMORY_MEM_ADD_RRSET adding RRset 'ok.ok.ok.ok.nsec3.tjeb.nl./NSEC3PARAM' into zone 'ok.ok.ok.ok.nsec3.tjeb.nl.'
2012-11-22 22:32:12.643 DEBUG [b10-auth.datasrc_memory] DATASRC_MEMORY_MEM_ADD_RRSET adding RRset 'tv3jp54nve7jfnhvba54uc031shjv2d3.ok.ok.ok.ok.nsec3.tjeb.nl./NSEC3' into zone 'ok.ok.ok.ok.nsec3.tjeb.nl.'
2012-11-22 22:32:12.643 DEBUG [b10-auth.datasrc_memory] DATASRC_MEMORY_MEM_ADD_ZONE adding zone 'ok.ok.ok.ok.nsec3.tjeb.nl./IN'

Is the problem simply that it cannot handle an NSEC3 that loops to itself?

Subtickets

Change History (14)

comment:1 in reply to: ↑ description Changed 7 years ago by jinmei

Replying to jelte:

Normal digs/drills for this data work, but for an NXDOMAIN or NOERROR/NODATA, it returns SERVFAIL.

The output log shows:

2012-11-22 22:25:00.912 ERROR [b10-auth.auth] AUTH_PROCESS_FAIL message processing failure: findNSEC3 attempt but zone has no NSEC3 RRs: ok.ok.ok.ok.nsec3.tjeb.nl./IN

note, this exception text occurs twice, I've confirmed it is the second case (trying to find origin node); loading itself works fine:

And I suspect the second one is a copy-paste bug. In any case the
message isn't really helpful in diagnose.

In this setup the NSEC3 domain tree has only one node for the owner
name of the only NSEC3 RR, so find(origin) wouldn't return an EXACTMATCH as
the code expects:

    ZoneTree::Result result =
         tree.find<void*>(origin_ls, &node, orig_chain, NULL, NULL);
    if (result != ZoneTree::EXACTMATCH) {
        // If the origin node doesn't exist, simply fail.
        isc_throw(DataSourceError,
                  "findNSEC3 attempt but zone has no NSEC3 RRs: " <<
                  origin_ls << "/" << getClass());
    }

Normally we have more than one NSEC3 RRs of different owner names
(different hashes), so the tree has an (empty) node for the origin
name.

I think what we should do is to explicitly insert the origin name to
the nsec3 tree, just like we do so for the normal zone tree.

comment:2 Changed 7 years ago by jwright

  • Defect Severity changed from N/A to Low
  • Milestone New Tasks deleted

comment:3 Changed 7 years ago by jelte

  • Estimated Difficulty changed from 0 to 3

comment:4 Changed 7 years ago by jelte

  • Milestone set to Sprint-20121218

comment:5 Changed 7 years ago by muks

  • Owner set to muks
  • Status changed from new to assigned

Picking

comment:6 follow-up: Changed 7 years ago by muks

I'm guessing the second SOA in the zone is also a copy-paste error.

comment:7 follow-up: Changed 7 years ago by muks

  • Owner changed from muks to UnAssigned
  • Status changed from assigned to reviewing

Up for review. I don't think a ChangeLog is necessary as it's a bugfix.

comment:8 in reply to: ↑ 7 Changed 7 years ago by jinmei

Replying to muks:

Up for review. I don't think a ChangeLog is necessary as it's a bugfix.

We generally provide changelog entries for bug fixes, and, I believe we need one
for this particular case.

comment:9 Changed 7 years ago by muks

ChangeLog entry for this bug:

+XXX.   [bug]           muks
+       Fixed a problem in inmem NSEC3 lookup which caused exceptions
+       in some cases.
+       (Trac #2503, git ...)
+

comment:10 in reply to: ↑ 6 ; follow-up: Changed 7 years ago by jelte

  • Owner changed from UnAssigned to muks

Replying to muks:

I'm guessing the second SOA in the zone is also a copy-paste error.

not related to the review or anything else in this ticket, but no, that was not a copy/paster error; the second SOA is part of the transfer protocol :)

Like in 2504 I replaced the zone contents with a zone 'example.com' instead of my zone origin.

And some comments:
zone_data.h:
The new parameter (zone_name) has no doxygen description. (also, the parameter name is zone_name in the header, but zone_origin in the implementation. Not a problem in practice, but inconsistent and potentially confusing)

I'm wondering if we shouldn't also test the case where the name exists but the type does not (in retrospect, maybe the same goes for 2504).

Also, I think we should probably mention that this specifically fixes a bug in the case where the zone only contains one name (also retrospectively for 2504).

comment:11 in reply to: ↑ 10 ; follow-up: Changed 7 years ago by muks

  • Owner changed from muks to jelte

Hi Jelte

Replying to jelte:

Replying to muks:

I'm guessing the second SOA in the zone is also a copy-paste error.

not related to the review or anything else in this ticket, but no, that was not a copy/paster error; the second SOA is part of the transfer protocol :)

Aha. The zone data loader threw an exception when it hit the second SOA, so I thought it was a mistake. Didn't think of transfers then. :)

Like in 2504 I replaced the zone contents with a zone 'example.com' instead of my zone origin.

Have you pushed this? I don't see it in the branch.

And some comments:
zone_data.h:
The new parameter (zone_name) has no doxygen description. (also, the parameter name is zone_name in the header, but zone_origin in the implementation. Not a problem in practice, but inconsistent and potentially confusing)

*nod*. This happened because I blindly cut and pasted the args from the ZoneData::create() args which had this issue too. Updated both now.

I'm wondering if we shouldn't also test the case where the name exists but the type does not (in retrospect, maybe the same goes for 2504).

Shall we do this as another ticket? It may involve code changes if there are bugs, and would be unrelated to this ticket.

Also, I think we should probably mention that this specifically fixes a bug in the case where the zone only contains one name (also retrospectively for 2504).

I've updated the ChangeLog for #2504 in master.

For this ticket, how about the following ChangeLog entry:

+XXX.   [bug]           muks
+       Fixed a problem in inmem NSEC3 lookup which caused exceptions
+       when the zone origin was not added as an explicit NSEC3 record.
+       (Trac #2503, git ...)
+

(Note that the cause for this ticket is different from the issue in #2504.)

comment:12 in reply to: ↑ 11 ; follow-up: Changed 7 years ago by jelte

  • Owner changed from jelte to muks

not related to the review or anything else in this ticket, but no, that was not a copy/paster error; the second SOA is part of the transfer protocol :)

Aha. The zone data loader threw an exception when it hit the second SOA, so I thought it was a mistake. Didn't think of transfers then. :)

Yeah I actually have script somewhere that does 'dig axfr' then strips off the last soa :)

Like in 2504 I replaced the zone contents with a zone 'example.com' instead of my zone origin.

Have you pushed this? I don't see it in the branch.

Indeed I had forgotten, done so now

I'm wondering if we shouldn't also test the case where the name exists but the type does not (in retrospect, maybe the same goes for 2504).

Shall we do this as another ticket? It may involve code changes if there are bugs, and would be unrelated to this ticket.

ok, i'll create one shortly

I've updated the ChangeLog for #2504 in master.

For this ticket, how about the following ChangeLog entry:

+XXX.   [bug]           muks
+       Fixed a problem in inmem NSEC3 lookup which caused exceptions
+       when the zone origin was not added as an explicit NSEC3 record.
+       (Trac #2503, git ...)
+

(Note that the cause for this ticket is different from the issue in #2504.)

I'd still put 'for instance when using a zone with no non-apex names' in those changelogs somewhere :) (that's what i would be looking for in a changelog if i had run into this problem)

But the changes look ok, and it can be merged

comment:13 in reply to: ↑ 12 Changed 7 years ago by muks

Hi Jelte

Replying to jelte:

For this ticket, how about the following ChangeLog entry:

+XXX.   [bug]           muks
+       Fixed a problem in inmem NSEC3 lookup which caused exceptions
+       when the zone origin was not added as an explicit NSEC3 record.
+       (Trac #2503, git ...)
+

(Note that the cause for this ticket is different from the issue in #2504.)

I'd still put 'for instance when using a zone with no non-apex names' in those changelogs somewhere :) (that's what i would be looking for in a changelog if i had run into this problem)

Done. :)

comment:14 Changed 7 years ago by muks

  • Resolution set to fixed
  • Status changed from reviewing to closed

Merged to master branch in commit 6fe86386be0e7598633fe35999112c1a6e3b0370:

* 3de3abb [2503] Replace private zone name with 'example.com'
* 422a1fc [2503] Update doxygen comment for renamed arg
* a9eef90 [2503] Rename arguments in protos to match what's used in definitions
* 7d7b752 [2503] Add doxygen comment for zone_name args
* c4b7c85 [2503] Check result of findNSEC3()
* 0d69a3d [2503] Insert the origin name into the NSEC3 tree by default
* c597146 [2503] Add testcase that reproduces the problem

Added the following ChangeLog entry:

523.    [bug]           muks
        Fixed a problem in inmem NSEC3 lookup (for, instance when using a
        zone with no non-apex names) which caused exceptions when the zone
        origin was not added as an explicit NSEC3 record.
        (Trac #2503, git 6fe86386be0e7598633fe35999112c1a6e3b0370)

Resolving as fixed. Thank you for the reviews and zone patch Jelte.

Note: See TracTickets for help on using tickets.