Discussion:
[Unbound-users] unbound 1.4.6 does not seem to have support of additional sections for NAPTR records
Lamers, Brian J (Brian)
2011-02-04 20:16:42 UTC
Permalink
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
Stephan Lagerholm
2011-02-05 16:11:10 UTC
Permalink
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-----
Sent: Friday, February 04, 2011 2:17 PM
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
Florian Weimer
2011-02-05 21:49:34 UTC
Permalink
Post by Stephan Lagerholm
Even with the logic in place in Unbound, there are still some other
Could the additional records expire independently, before the actual
answer RRset?

I'm really not sure if additional section processing is worth the
complexity.
Stephan Lagerholm
2011-02-06 16:57:24 UTC
Permalink
Post by Florian Weimer
I'm really not sure if additional section processing is worth the
complexity.
For a normal Internet DNS, getting the MX as an additional RR it
certainly is worth it to save one query when mails are being sent.

In wireless LTE networks, NAPTR and SRV are being used for node
selection. I don't know the exact implications but I can see why LTE
equipment vendors would like to shave off a few milliseconds by avoiding
sending multiple queries.

/S
----------------------------------------------------------------------
Stephan Lagerholm
Senior DNS Architect, M.Sc. ,CISSP
Secure64 Software Corporation, www.secure64.com
Cell: 469-834-3940
Post by Florian Weimer
-----Original Message-----
Sent: Saturday, February 05, 2011 3:50 PM
To: Stephan Lagerholm
Subject: Re: [Unbound-users] unbound 1.4.6 does not seem to have
support of
Post by Florian Weimer
additional sections for NAPTR records
Post by Stephan Lagerholm
Even with the logic in place in Unbound, there are still some other
Could the additional records expire independently, before the actual
answer RRset?
I'm really not sure if additional section processing is worth the
complexity.
Florian Weimer
2011-02-06 17:10:51 UTC
Permalink
Post by Stephan Lagerholm
Post by Florian Weimer
I'm really not sure if additional section processing is worth the
complexity.
For a normal Internet DNS, getting the MX as an additional RR it
certainly is worth it to save one query when mails are being sent.
There is no way to signal the absence of an AAAA RRset, so you still
have to make another round-trip to the DNS resolver if you're
IPv6-enabled and the MXes aren't. (A and AAAA RRsets aren't cached as
an atomic unit.)
Stephan Lagerholm
2011-02-07 02:58:31 UTC
Permalink
Post by Florian Weimer
Post by Stephan Lagerholm
Post by Florian Weimer
I'm really not sure if additional section processing is worth the
complexity.
For a normal Internet DNS, getting the MX as an additional RR it
certainly is worth it to save one query when mails are being sent.
There is no way to signal the absence of an AAAA RRset, so you still
have to make another round-trip to the DNS resolver if you're
IPv6-enabled and the MXes aren't. (A and AAAA RRsets aren't cached as
an atomic unit.)
Good point. I wonder how many MTAs that actually check that...
Florian Weimer
2011-02-07 05:44:27 UTC
Permalink
Post by Stephan Lagerholm
Post by Florian Weimer
There is no way to signal the absence of an AAAA RRset, so you still
have to make another round-trip to the DNS resolver if you're
IPv6-enabled and the MXes aren't. (A and AAAA RRsets aren't cached as
an atomic unit.)
Good point. I wonder how many MTAs that actually check that...
Exim does. We learnt it the hard way, after seeing failures in the
field.

Loading...