Hi Brian, You are right in that Unbound doesn't keep the relevant records in the additional section when a NAPTR is encountered. This is different from ISC bind that appears to keep the relevant records.
Note that Unbound is not doing anything wrong here, you asked for a NAPTR and you got a NAPTR back. The client (you) need to figure out the meaning of the NAPTR and send additional queries if needed. Even with the logic in place in Unbound, there are still some other conditions that must be met: 1. The authoritative server must populate the additional section with the relevant A/AAAA/SRV when asked for the NAPTR. Not all do, for example I believe that NSD will not do that. As a sidenote, Authoritative bind appears to be a little bit buggy here when answering a NAPTR query with a "S" flag. It sends the final expanded A record in the additional section but forgets to send the SRV record. You can see this when digging: dig adobe.com NAPTR (The usefulness of the A record for voipproxy1.adobe.com is somewhat limited since the SRV is not sent) 2. Unbound is "paranoid" about the additional section and will drop everything that is "out of bailiwick". So if a NAPTR under example.net points to an A/AAAA/SRV record under other.com. that record will be stripped. This is not unique to NAPTR, the same stripping will be done for MX for example. Other name servers might not be as "paranoid" so you better be. You might end up with security issues if you start trusting what servers are sending in the additional section. 3. Intermediate DNS systems might have minimal-responses turned on to strip the additional section. (Unbound does not support this feature, but others do Bind, Secure64, etc). So in the case when: - The authoritative server is populating the additional section when queried for NAPTR (1) and - Is doing that correctly even for SRV records (sidenote) and - The data is "in bailiwick" (2) and - There are no intermediate DNS caches (forwarders for example) that potentially could strip the additional section (3) Then, yes. You will need 2 (or 3 in the SRV case) queries to Unbound and only one to Bind to get the final answer. /S ---------------------------------------------------------------------- Stephan Lagerholm Senior DNS Architect, M.Sc. ,CISSP Secure64 Software Corporation, www.secure64.com Cell: 469-834-3940 >-----Original Message----- >From: [email protected] [mailto:unbound-users- >[email protected]] On Behalf Of Lamers, Brian J (Brian) >Sent: Friday, February 04, 2011 2:17 PM >To: [email protected] >Subject: [Unbound-users] unbound 1.4.6 does not seem to have support of >additional sections for NAPTR records > >It appears that additional section records are dropped from NAPTR records >queries by unbound. I glanced at the code and it looked like there was a TODO >comment by the NAPTR case for keeping additional records. It seems A/AAAA/SRV >records were supported and I was able to verify that SRV records kept the >relevant A/AAAA additional records and past to the client. > >Does anyone know if NAPTR records will ever support keeping additional records >and passing to the client? Is there an issue with supporting NAPTR vs SRV >records? > >Thanks for any feedback, >Brian > _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
