Hello, I noticed that the "rd" flag was missing from the output of a standard (recursive) dig against some (*) of the name-services.com name servers: $ dig @dns5.name-services.com. name-services.com. | grep flags ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
(*) dns1 and dns5 show this behavior, dns2-4 are "normal". Using dig.pl (Net::DNS::Toolkit): $ dig.pl -h @dns5.name-services.com. name-services.com. ID => 4439 QR => 0 OPCODE => QUERY AA => 0 TC => 0 RD => 1 RA => 0 Z => 0 AD => 0 CD => 0 RCODE => NOERROR QDCOUNT => 1 ANCOUNT => 0 NSCOUNT => 0 ARCOUNT => 0 ID => 4439 QR => 1 OPCODE => QUERY AA => 1 TC => 0 RD => 0 RA => 0 Z => 0 AD => 0 CD => 0 RCODE => NOERROR QDCOUNT => 1 ANCOUNT => 1 NSCOUNT => 5 ARCOUNT => 5 ; <<>> dig.pl 1.11 <<>> -h @dns5.name-services.com. name-services.com. ;; ;; Got answer. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4439 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5 <snip> RD is set to 1 in the query, but is 0 in the response. Which is not compliant with RFC 1035: "RD Recursion Desired - this bit may be set in a query and is copied into the response." Out of curiosity, any idea why a name server would want to change the RD bit ? (except to break an unsuspecting script ;) Thanks and regards, -- craig _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
