[Unbound-users] unbound 1.4.6 does not seem to have support of additional sections for NAPTR records

Stephan Lagerholm stephan.lagerholm at secure64.com
Sat Feb 5 16:11:10 UTC 2011


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: unbound-users-bounces at NLnetLabs.nl [mailto:unbound-users-
>bounces at NLnetLabs.nl] On Behalf Of Lamers, Brian J (Brian)
>Sent: Friday, February 04, 2011 2:17 PM
>To: unbound-users at unbound.net
>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
>




More information about the Unbound-users mailing list