Trusted upstream resolver

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi John,

On 29/10/15 17:29, Woodworth, John R via Unbound-users wrote:
> Hello,
> 
> 
> 
> I am involved in a scenario where a satellite link is being used
> to serve an office and latency is of great concern.
> 
> 
> 
> The problem at hand is CNAME resolution which is followed by
> validation of provided A records.  I understand that under normal
> conditions the A records provided with the initial CNAME response
> can lead to cache poisoning so they are validated from an
> authority.  However, this leads to doubling the lookup time which
> typically exceeds 1.5 seconds. Although the difference may seem
> trivial the additional ~650ms becomes very noticeable by the end
> users.  I’ve provided a short example below.
> 
> 
> 
> 0.001 [Client]->[Resolver]->A?www.example.com
> 
> 0.002       [Resolver]->X[Auth]->A?www.example.com
> 
> 0.758       [Auth]->X[Resolver]->CNAME:www2.example.com+1.2.3.4
> 
> 0.761       [Resolver]->X[Auth]->A?www2.example.com
> 
> 1.622       [Auth]->X[Resolver]->A:1.2.3.4
> 
> 1.625 [Resolver]->[Client]->A:1.2.3.4
> 
> 
> 
> NOTE: X == Satellite Link
> 
> 
> 
> 
> 
> My thought is to use another nameserver at the other end of the
> link which can provide this validation feature but is “trusted” by
> the near-end nameserver server reducing the RTT for local clients.
> As an aside, the far-end nameserver already exists for other
> purposes.  I’ve provided a short example of this idea below.
> 
> 
> 
> 0.001 [Client]->[Resolver]->A?www.example.com
> 
> 0.002       [Resolver]->X[Resolver2]->A?www.example.com
> 
> 0.288             [Resolver2]->[Auth]->A?www.example.com
> 
> 0.290
> [Auth]->[Resolver2]->CNAME:www2.example.com+1.2.3.4
> 
> 0.292             [Resolver2]->[Auth]->A?www2.example.com
> 
> 0.301             [Auth]->[Resolver2]->A:1.2.3.4
> 
> 0.655       [Resolver2]->X[Resolver]->A:1.2.3.4
> 
> 0.659 [Resolver]->[Client]->A:1.2.3.4
> 
> 
> 
> NOTE: X == Satellite Link
> 
> 
> 
> Is there a configuration option I am overlooking to disable these
> A record validations (from Resolver to Resolver2)?

No, there is no option to disable the CNAME checks.  The trust in the
other nameserver is by the way not enough reason to have used such an
option, it is protection against inserted spoofed packets here that
has mandated the checks.

Consider enabling prefetch: yes   (and prefetch-key: yes) in
unbound.conf, for commonly asked queries that will make it prefetch a
couple seconds before expiry to refresh the cache entry, and that
should be enough to hide this latency for a larger number of queries.

Another option, but less desirable, is cache-min-ttl where you can
force entries to stay in the cache for a longer time (i.e. that CNAME
was from a CDN with very short TTLs).

Best regards, Wouter

> 
> 
> 
> 
> 
> Thanks,
> 
> John
> 
> --
> 
> John Woodworth                          CenturyLink, Inc.
> 
> Q. Can BULK DNS Handle 18 Quintillion PTR Records??
> 
> A. BULK CAN            (18,446,744,073,709,551,616 +)
> 
> [ http://tools.ietf.org/html/draft-woodworth-bulk-rr-00 ]
> 
> 
> 
> This communication is the property of CenturyLink and may contain 
> confidential or privileged information. Unauthorized use of this 
> communication is strictly prohibited and may be unlawful. If you
> have received this communication in error, please immediately
> notify the sender by reply e-mail and destroy all copies of the
> communication and any attachments.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWOL06AAoJEJ9vHC1+BF+NDgcP/j24U6YNlQ1uzIWNeMaWhqmC
QfVxT3PVs65pgHrU+NBQSOSoTiKkjLAuSPdQ5rNJf7Pdhv1gNqDfe1VtIl5mD0dQ
FT5NibOHPNxefNdL1uAvSa1F+sBxNINa/uCloDAztoi1oPkiqG41caK9bjsZBhRB
+UMvopnB5IIUrfz/CA1MEM5QLB9CKKxcdaXeE6AUrH/DxRd67fMZywI0bCqL3tnp
LhB7GVO7M5RIAeY8YwYzTFu7fNGcRa5vSMpCLW0nXGln8qPlycZ0Ujktk2OM4FrS
mnVXAxn+B5iYWTVFehQqB9k3rlHm6GgZQL6GfL5BmPJpNkSC1MkRQSllQULQCxAa
3PWH+MX9xjm4KS8K/6dCBQUUKVb7az6kUePnz6T3a9Oo45310xdh5px00y57Xn9J
BmPSq5ghyy7ssWhfOLesRZtvfoulmx9aKPjBsnr+javvWxdHVym+danXPKk9fAbp
He7xOYqt/MqYZW5ttzufyKA/cYl12pexon4kpsqFeq2EGRFSemUDegbjdPG1wIgX
ZungXNshOlcD5TqvItNPDYqEfGWSlgypBj7pgF8q6AbjOCFhDwg0UPfHQhm0TmtN
OmMy+k2TeX7dDk3yOQIKUcZelC0pKFwJoQYFpfOy/c2TklO2Ey1CK3UXNXqEpksa
H0MLAm8LkZqdT9sulKY9
=PI38
-----END PGP SIGNATURE-----