In message <caektliqyxgmivhw7prifcy3qwby4szjzm8bjz48jj4umooc...@mail.gmail.com> , Casey Deccio writes: > > Hi Alexei, > > On Fri, Dec 5, 2014 at 2:31 PM, Alexei Malinin <alexei.mali...@mail.ru> > wrote: > > > 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 > child. > > For example: > > $ dig +noall +comments +authority @ns1.agtel.net > 0-15.66.233.212.in-addr.arpa ds > ;; 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. > > Casey
With all this said a RFC 2317 parent really should let their zone be transfered as the child zone administrator needs a local copy of the zone for when their external link goes down. If they do not have a local copy then reverse lookups will fail once the cached CNAME records expire. If your ISP uses RFC 2317 and doesn't allow you to transfer the zone go find a ISP knows what they are doing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users