You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the query, <something.bar.foo.campus.edu., A>, NSD returns the ns3 record, whereas others like Bind return ns2.
NSD works well in all other cases, like ignoring other types (say A record) of records below delegation and also not returning a glue record by returning the zone cut NS record. This is the only case I found where NSD behaves differently.
RFC 2181 clarifies that no data below the zone cut may appear at the parental side. Since this is the only case, I am guessing NSD chose this response to reduce RTT (?), but it would be helpful if nsd-checkzone gave a warning. I am raising an issue to know why this case is only handled specially.
The text was updated successfully, but these errors were encountered:
Thanks for the report! Fixed this by having the delegation point lookup function use the highest delegation point, instead of the lowest delegation point, in case where the zone has more than one for the query.
Hi,
When a zone file has NS records below a delegation, NSD returns those NS records instead of using the earlier zone cut records.
Consider the following sample zone file:
For the query,
<something.bar.foo.campus.edu., A>
, NSD returns thens3
record, whereas others like Bind returnns2
.NSD works well in all other cases, like ignoring other types (say
A
record) of records below delegation and also not returning a glue record by returning the zone cut NS record. This is the only case I found where NSD behaves differently.RFC 2181 clarifies that no data below the zone cut may appear at the parental side. Since this is the only case, I am guessing NSD chose this response to reduce RTT (?), but it would be helpful if
nsd-checkzone
gave a warning. I am raising an issue to know why this case is only handled specially.The text was updated successfully, but these errors were encountered: