DNS: how to verify glue NS records?
casey at deccio.net
Fri Dec 5 19:49:23 UTC 2014
On Fri, Dec 5, 2014 at 2:31 PM, Alexei Malinin <Alexei.Malinin at mail.ru>
> Thank you for the explanation.
> I'm sorry for the misleading Subject of this thread, of course I meant
> "delegation NS records".
No problem. I knew what you meant :)
> I understand from your reply that there are no technical means, tools,
> etc for verifying delegation NS records in the parent zone if the child
> and parent zone are on the same authoritative name server and zone
> transfers from that server are prohibited. Is my conclusion correct?
Yes. If any parent authoritative server is *not* authoritative for the
child, then the delegation records can be identified by querying *that
server* for a referral. Otherwise, the delegation NS RRset cannot be
gleaned from outside queries.
There is one slight exception to this. You *can* learn if the parent has
*no* delegation records at all by using a DS query. This is a corner case
but sometimes happens if the operator has neglected to place the
appropriate delegation records in the parent zone and doesn't see the
problem because, excepting a DS query (for which the *parent* is
authoritative, for DNSSEC purposes), the NS response always come from the
child when both parent and child zones are hosted on the same server. If
you query a server authoritative for both parent and child for DS, an
NXDOMAIN response means that the parent has no delegation records for the
$ dig +noall +comments +authority @ns1.agtel.net
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30614
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; AUTHORITY SECTION:
66.233.212.in-addr.arpa. 3600 IN SOA ns1.agtel.net.
hostmaster.agtel.net. 2014120402 86400 3600 604800 86400
The SOA record indicates that the response indeed came from the parent zone
(66.233.212.in-addr.arpa), and the NOERROR response indicates that there
are delegation NS records for in the parent zone.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users