>>>> For instance, some authoritative name servers embedded in load >>>> balancers reply properly to A queries but send REFUSED to NS queries.
>> If my policy is not to tell you about NS records, that's my policy. >> It may be a stupid policy that causes downstream problems, but it's my >> right to be stupid. > >Being listed as nameserver while unconditionally refusing all NS queries >leads to a guaranteed failure with DNSSEC as there would not be a signed >NS RRset published anywhere. Yes, we agree it could have bad results. > The NS RR states that the named host should be expected to have a zone > starting at owner name of the specified class. > >I would interpret that to mean that a parental NS glue record signifies >that the RDATA target must point to something that has that zone at the >owner name. Thus the NS queries at that target should return proper >results for NS queries (to itself) Unless, of course, the target doesn't like you and refuses your queries for policy reasons. Maybe they don't want you to be able to tell if there are delegated subzones, or they just think you're ugly. It's still their policy, so they can refuse the queries. The language in section 4.1.1 of RFC 1035 that defines the refused RCODE is simple, and in a quick look at other RFCs that update 1035, I didn't see anything that updates the definition. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
