Re: DNS: how to verify glue NS records?
Thanks to all for your replies but... I'm sorry for the misleading Subject of this thread, I meant "delegation NS records" (not "glue records"). Below is the answer from bind-us...@lists.isc.org. -- Alexei Original Message -------- Subject: Re: DNS: how to verify glue NS records? Date: Fri, 5 Dec 2014 10:39:28 -0500 From: Casey Deccio To: Alexei Malinin CC: Bind Users Hi Alexei, On Fri, Dec 5, 2014 at 10:16 AM, Alexei Malinin wrote: > I would like to resolve this problem: > - I have a child DNS zone served by my ISP slave name server; > - the parent zone is served by my ISP master name server; > - the question is - how and with what tools (dig, host, nslookup, or > maybe C or Perl libs) can I verify the NS glue records in the parent > zone of my ISP (zone transfers are denied)? The delegation NS records (i.e., the NS records in the parent zone) cannot be determined using simple queries because the parent zone is also authoritative for the child zone, as you mentioned. Thus, when one of those servers (e.g., ns1.agtel.net) is queried for 0-15.66.233.212.in-addr.arpa/NS, the server will (should) always send the authoritative NS RRset in (i.e., from the child) preference to the delegation NS RRset (i.e., in the parent), and in fact the latter may be different. There are by definition no glue records for your zone. Glue A/ records are only required in the parent for NS targets that are subdomains of the delegated child zone to bootstrap resolution. For example, ns1.example.com as an NS target for example.com. That is not the case with yours (and usually isn't with in-addr.arpa zones). > My child zone is 0-15.66.233.212.in-addr.arpa. I tried "dig -4 > +multiline +showsearch +trace 0-15.66.233.212.in-addr.arpa ns" but it > was not possible to make any conclusions about NS glue records from the > dig output. >. > I found some tools in the Internet (for example > http://www.intodns.com/0-15.66.233.212.in-addr.arpa, see "Missing > nameservers reported by parent") but these are inconvenient, I would > like to use OS tools. That's unfortunately a misleading error, as this cannot be determined, as I mentioned above. > Please give me some good advise. You'll need to take the word of the operator of your parent zone. Casey
Re: DNS: how to verify glue NS records?
Thus said Alexei Malinin on Fri, 05 Dec 2014 15:49:59 +0300: > - the question is - how and with what tools (dig, host, nslookup, or > maybe C or Perl libs) can I verify the NS glue records in the parent > zone of my ISP (zone transfers are denied)? The entries in the ADDITIONAL SECTION below are ``glue records'' for the NS records in the ANSWER SECTION. The problem you have, however, DNS resolvers are going to have to make a lot of additional DNS requests to be able to determine if the glue can be used. For the glue to be immediately trusted, it would have to be in-bailiwick (e.g. ns1.0-15.66.233.212.in-addr.arpa and ns2.0-15.66.233.212.in-addr.arpa). But, At any rate, there you have it, glue is found in the ADDITIONAL SECTION: $ dig ptr 1.0-15.66.233.212.in-addr.arpa @ns1.agtel.net ; <<>> DiG 9.4.2-P2 <<>> ptr 1.0-15.66.233.212.in-addr.arpa @ns1.agtel.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37069 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 7 ;; QUESTION SECTION: ;1.0-15.66.233.212.in-addr.arpa.IN PTR ;; ANSWER SECTION: 1.0-15.66.233.212.in-addr.arpa. 43200 IN PTRdynamic-212-233-66-1.amt.ru. ;; AUTHORITY SECTION: 0-15.66.233.212.in-addr.arpa. 43200 IN NS ns58-cloud.nic.ru. 0-15.66.233.212.in-addr.arpa. 43200 IN NS ns1.agtel.net. 0-15.66.233.212.in-addr.arpa. 43200 IN NS ns2.agtel.net. 0-15.66.233.212.in-addr.arpa. 43200 IN NS ns4-l5.nic.ru. 0-15.66.233.212.in-addr.arpa. 43200 IN NS ns8-l5.nic.ru. 0-15.66.233.212.in-addr.arpa. 43200 IN NS ns54-cloud.nic.ru. ;; ADDITIONAL SECTION: ns1.agtel.net. 600 IN A 212.111.64.132 ns2.agtel.net. 600 IN A 212.233.88.2 ns4-l5.nic.ru. 25082 IN A 91.217.20.13 ns8-l5.nic.ru. 36736 IN A 91.217.21.13 ns54-cloud.nic.ru. 19033 IN A 195.253.64.16 ns54-cloud.nic.ru. 19033 IN 2a01:5b0:4::10 ns58-cloud.nic.ru. 12582 IN A 195.253.65.16 ;; Query time: 273 msec ;; SERVER: 212.111.64.132#53(212.111.64.132) ;; WHEN: Sun Dec 7 23:03:49 2014 ;; MSG SIZE rcvd: 354 Andy -- TAI64 timestamp: 400054854018
Re: DNS: how to verify glue NS records?
On Fri, Dec 05, 2014 at 03:49:59PM +0300, Alexei Malinin wrote: > > I would like to resolve this problem: > - I have a child DNS zone served by my ISP slave name server; > - the parent zone is served by my ISP master name server; It appears to me what you refer to as "master name server" above are also part of the "slave name server" set? Parent zone: --- $ dig +nssearch 66.233.212.in-addr.arpa. SOA ns1.agtel.net. hostmaster.agtel.net. 2014120402 86400 3600 604800 86400 from server ns2.agtel.net in 22 ms. SOA ns1.agtel.net. hostmaster.agtel.net. 2014120402 86400 3600 604800 86400 from server ns1.agtel.net in 24 ms. --- Child zone: --- $ dig +nssearch 0-15.66.233.212.in-addr.arpa. SOA ns.amt.ru. hostmaster.amt.ru. 2014120415 3600 1800 4233600 3600 from server ns8-l5.nic.ru in 106 ms. SOA ns.amt.ru. hostmaster.amt.ru. 2014120415 3600 1800 4233600 3600 from server ns54-cloud.nic.ru in 53 ms. SOA ns.amt.ru. hostmaster.amt.ru. 2014120415 3600 1800 4233600 3600 from server ns1.agtel.net in 68 ms. SOA ns.amt.ru. hostmaster.amt.ru. 2014120415 3600 1800 4233600 3600 from server ns58-cloud.nic.ru in 86 ms. SOA ns.amt.ru. hostmaster.amt.ru. 2014120415 3600 1800 4233600 3600 from server ns2.agtel.net in 47 ms. SOA ns.amt.ru. hostmaster.amt.ru. 2014120415 3600 1800 4233600 3600 from server ns4-l5.nic.ru in 51 ms. --- Basically you would want to compare the NS records reported by one of the hosts in the first set, with the NS records reported by one of the hosts in the second set. This only compares the delegation NS records with the authoritative NS records though, not glue (see below). > > - the question is - how and with what tools (dig, host, nslookup, or > maybe C or Perl libs) can I verify the NS glue records in the parent > zone of my ISP (zone transfers are denied)? > My first reaction is that I am not sure what you mean by "NS glue records". There are "NS records" and then there are "glue records". The NS records in the parent zone may also be called "delegation records". Actual "glue records" (A/) are only needed when the NS records contain names that are inside the zone they are authoritative for. These should only exist in the parent zone for the actual names mentioned in the NS records. We can take ns1.agtel.net as an example: --- $ dig +trace ns1.agtel.net [...] agtel.net. 172800 IN NS ns2.agtel.net. agtel.net. 172800 IN NS ns1.agtel.net. ;; Received 95 bytes from 192.5.6.30#53(a.gtld-servers.net) in 183 ms [...] --- In this case, a.gtld-servers.net delegates agtel.net to ns1.agtel.net. Since ns1.agtel.net is inside the zone agtel.net, a glue record is necessary in the parent zone, we can look it up like so: --- dig @a.gtld-servers.net agtel.net [...] ;; ADDITIONAL SECTION: ns2.agtel.net. 172800 IN A 212.233.88.2 ns1.agtel.net. 172800 IN A 212.111.64.132 [...] --- The ADDITIONAL SECTION contains the glue records for the nameservers in agtel.net. And they have nothing to do with your reverse 0-15.66.233.212.in-addr.arpa zone. To verify glue you would need to check this for the other nameservers mentioned in NS records for your reverse zone. > > I found some tools in the Internet (for example > http://www.intodns.com/0-15.66.233.212.in-addr.arpa, see "Missing > nameservers reported by parent") but these are inconvinient, I would > like to use native OS tools (or tools from ports). > Based on the contents of the result field ("OK. All NS records are the same at the parent and at your nameservers.") It appears to me this test compares your authoritative NS records with the delegation NS records in the parent. It does not look like it has anything to do with glue records. Sorry if all this is obvious to you and I am missing the bigger picture. Just trying to understand what you are asking for :). Regards, Patrik Lundin
Re: DNS: how to verify glue NS records?
On 2014-12-05 Fri 15:49 PM |, Alexei Malinin wrote: > > My child zone is 0-15.66.233.212.in-addr.arpa. I tried "dig -4 > +multiline +showsearch +trace 0-15.66.233.212.in-addr.arpa ns" but it > was not possible to make any conclusions about NS glue records from the > dig output. > Try this Alexei: $ dnstracer -4 -q ptr -c -o -s . 0-15.66.233.212.in-addr.arpa The final overview table is missing == unglued. e.g: compared to: $ dnstracer -4 -q ptr -c -o -s . 83.122.109.193.in-addr.arpa .. . ... .. . ns.paphosting.nl (94.142.245.3) 83.122.109.193.in-addr.arpa -> www.undeadly.org $ pkg_info dnstracer Information for inst:dnstracer-1.9 Comment: domain name system resolution tracer Description: Dnstracer determines where a given Domain Name Server (DNS) gets its information from and follows the chain of DNS servers back to the servers which know the data. Its behaviour is similar to ntptrace(8), which does it for the NTP protocol. Maintainer: joshua stein WWW: http://www.mavetju.org/unix/dnstracer.php -- Glasgow Rvierside (technology) Museum trip (2013 winner best in Europe): https://twitter.com/Craig_Skinner/status/536497503181762560
DNS: how to verify glue NS records?
Hello. I would like to resolve this problem: - I have a child DNS zone served by my ISP slave name server; - the parent zone is served by my ISP master name server; - the question is - how and with what tools (dig, host, nslookup, or maybe C or Perl libs) can I verify the NS glue records in the parent zone of my ISP (zone transfers are denied)? My child zone is 0-15.66.233.212.in-addr.arpa. I tried "dig -4 +multiline +showsearch +trace 0-15.66.233.212.in-addr.arpa ns" but it was not possible to make any conclusions about NS glue records from the dig output. I found some tools in the Internet (for example http://www.intodns.com/0-15.66.233.212.in-addr.arpa, see "Missing nameservers reported by parent") but these are inconvinient, I would like to use native OS tools (or tools from ports). Please give me some good advise. -- Alexei Malinin