Twiglets
Senior Member
This is difficult, for me, to explain without getting very low level into how DNS Records are constructed and what the various fields do and how they impact the operation of your resolver (unbound/dnsmasq/BIND/etc).
These examples are contrived/nonsensical uses of nameservers to try to simplify the explanation !!!
From the unbound docs:
Reading this data is, of course, something that takes time and slows the apparent time to get a reply.[Latency]
The upside is that the nameserver DNS data is stored/cached and if queries are made refering to the same nameserver you gain from the faster response.
The target-fetch-policy setting has values for different "depths.".
Example Query:
You have a query that is for 'QWE.net' which leads to DNS records that point at NS1.com & NS2.com & NS3.com. [3 nameserver addresses]
These records state that the authorative IP address is obtained from any/all of NS1.com & NS2.com & NS3.com.
NS1.com & NS2.com are defined as Authorative nameservers.
NS3.com is a local internal Authorative nameserver that you can change.
'QWE.com' resolves as 111.222.111.111 and is only defined on NS3.com, for now.
NS1.com contains DNS records defining 'QWE.net' as 111.222.111.111
NS2.com contains DNS records defining 'QWE.net' as 111.222.111.111
NS3.com contains DNS records defining 'QWE.net' as CNAME 'QWE.com' (requiring further lookup to resolve.)
NS1.com & NS2.com are yet to be updated to resolve 'QWE.net' as CNAME 'QWE.com' & 'QWE.com' to be added to them.
'QWE.net' as CNAME 'QWE.com' means == 'QWE.net' is an alias for 'QWE.com'
You will be able to access 'QWE.net' or 'QWE.com' and they are the same IP address.
[Depth examples]--------------------------------------------------------------------------------
If 'target-fetch-policy:' was defined as "2 1 0 0 0" then unbound would lookup 2 of the 3 NS addresses because 2 is the 1st level defined.
[It would be the 1st 2 server addresses it retrieved from the records in the DNS definition for QWE.net.]
The first 2 nameservers will resolve directly to 111.222.111.111.
Unbound knows the DNS details of NS1, NS2 and has resolved QWE.net.
[No further action needed]
If 'target-fetch-policy:' was defined as "3 2 1 0 0" then unbound would lookup 3 of the 3 addresses because 3 is the 1st level defined.
[It would be the 3 server addresses it retrieved from the records in the DNS definition for QWE.net.]
The first 2 nameservers will resolve directly to 111.222.111.111 as above.
The 3rd namesever would return QWE.com which would require a further query to resolve it.
Unbound knows the DNS details of NS1, NS2, NS3 and has resolved QWE.net & QWE.com as 111.222.111.111
[No further Action]
If 'target-fetch-policy:' was defined as "-1 -1 -1 -1 -1" then unbound would lookup 3 of the 3 addresses because 3 is the maximum addresses available from the query. (-1 means retrieve ALL the targets at this level, which equals 3 in this case)
It would then drop down to the next level and resolve all the querys at this level, which in this example equals Zero.
This would give the same result as the "3 2 1 0 0' example, in this case.
If at a level a nameserver resolves a query to an answer that need to access another unknown nameserver ... that is a drop to a lower level.
[The next number in the "3 2 1 0 0 0' sequence, for instance.]
At that lower level the same rules apply ... unbound can query 'opportunistically' 2, the next number in this case, nameserver addresses if it does not already have the DNS data.
This is the pre-fetching that caches information that may be useful for future queries.
The more unbound does this the more busy unbound gets doing queries for data that is not dirrectly asked for by a DNS client.
This extra data is cached and ALL this extra processing impacts latency of requests for DNS clients.
The upside is that these queries don't have to be made again if the next time a request needs the data it is already in the cache.
This is the other side of the equation in speeding up unbound.
N.B.
In regard to 'harden-referral-path: ' ... See below
These examples are contrived/nonsensical uses of nameservers to try to simplify the explanation !!!
From the unbound docs:
This impacts the effective 'pre-fetching' of nameserver DNS data based on the queries being made.
Reading this data is, of course, something that takes time and slows the apparent time to get a reply.[Latency]
The upside is that the nameserver DNS data is stored/cached and if queries are made refering to the same nameserver you gain from the faster response.
The target-fetch-policy setting has values for different "depths.".
Example Query:
You have a query that is for 'QWE.net' which leads to DNS records that point at NS1.com & NS2.com & NS3.com. [3 nameserver addresses]
These records state that the authorative IP address is obtained from any/all of NS1.com & NS2.com & NS3.com.
NS1.com & NS2.com are defined as Authorative nameservers.
NS3.com is a local internal Authorative nameserver that you can change.
'QWE.com' resolves as 111.222.111.111 and is only defined on NS3.com, for now.
NS1.com contains DNS records defining 'QWE.net' as 111.222.111.111
NS2.com contains DNS records defining 'QWE.net' as 111.222.111.111
NS3.com contains DNS records defining 'QWE.net' as CNAME 'QWE.com' (requiring further lookup to resolve.)
NS1.com & NS2.com are yet to be updated to resolve 'QWE.net' as CNAME 'QWE.com' & 'QWE.com' to be added to them.
'QWE.net' as CNAME 'QWE.com' means == 'QWE.net' is an alias for 'QWE.com'
You will be able to access 'QWE.net' or 'QWE.com' and they are the same IP address.
[Depth examples]--------------------------------------------------------------------------------
If 'target-fetch-policy:' was defined as "2 1 0 0 0" then unbound would lookup 2 of the 3 NS addresses because 2 is the 1st level defined.
[It would be the 1st 2 server addresses it retrieved from the records in the DNS definition for QWE.net.]
The first 2 nameservers will resolve directly to 111.222.111.111.
Unbound knows the DNS details of NS1, NS2 and has resolved QWE.net.
[No further action needed]
If 'target-fetch-policy:' was defined as "3 2 1 0 0" then unbound would lookup 3 of the 3 addresses because 3 is the 1st level defined.
[It would be the 3 server addresses it retrieved from the records in the DNS definition for QWE.net.]
The first 2 nameservers will resolve directly to 111.222.111.111 as above.
The 3rd namesever would return QWE.com which would require a further query to resolve it.
Unbound knows the DNS details of NS1, NS2, NS3 and has resolved QWE.net & QWE.com as 111.222.111.111
[No further Action]
If 'target-fetch-policy:' was defined as "-1 -1 -1 -1 -1" then unbound would lookup 3 of the 3 addresses because 3 is the maximum addresses available from the query. (-1 means retrieve ALL the targets at this level, which equals 3 in this case)
It would then drop down to the next level and resolve all the querys at this level, which in this example equals Zero.
This would give the same result as the "3 2 1 0 0' example, in this case.
If at a level a nameserver resolves a query to an answer that need to access another unknown nameserver ... that is a drop to a lower level.
[The next number in the "3 2 1 0 0 0' sequence, for instance.]
At that lower level the same rules apply ... unbound can query 'opportunistically' 2, the next number in this case, nameserver addresses if it does not already have the DNS data.
This is the pre-fetching that caches information that may be useful for future queries.
The more unbound does this the more busy unbound gets doing queries for data that is not dirrectly asked for by a DNS client.
This extra data is cached and ALL this extra processing impacts latency of requests for DNS clients.
The upside is that these queries don't have to be made again if the next time a request needs the data it is already in the cache.
This is the other side of the equation in speeding up unbound.
N.B.
In regard to 'harden-referral-path: ' ... See below
Last edited:
]
