So, the short answer is that check-names is pretty granular, doing "check-names response fail" is just asking for trouble, for a resolver at the Internet edge, since there's too much squirrely stuff out there. Most folks just limit check-names "fail" to authoritative data (master or slave).
The longer answer is: this is an interesting standards-compliance question. The rule is that a "hostname" can't contain an underscore. Owner names that aren't "hostnames" are allowed to have underscores. I believe -- I could be mistaken -- that owner names for MX records, for instance, can have underscores. In some cases, underscores were *purposely* encoded into owner names, for certain record types, *because* that way, they could never collide with "hostnames". SRV records are an example of that. But, in this case, the "hostname" is www.newegg.com -- no underscore. For that matter, the owner name of the A record -- e5638.g.akamaiedge.net -- doesn't contain an underscore either. So, the only names that are involved in the resolution of this name, that contain underscores, are *intermediate* CNAMEs between the original name (www.newegg.com) and the ultimate owner of the A record -- names that a user never sees or deals with when accessing the resource. Does it therefore violate the "hostnames can't contain underscores" rule or not? That's a very debatable question. Having said that, however, Akamai violates a different rule by chaining CNAMEs ("Domain names in RRs which point at another name should always point at the primary name and not the alias" -- RFC 1034). In fact, their whole business model is based on this standards-violation, and it's worked very well for them. Now, I don't really have a fundamental problem with Akamai, as a company; we use them extensively, including their "Fast DNS" service, which basically consists of replicating our zones to their DNS-CDN. But the standards-purist in me still rankles at the fact that they're based on a standards-violation. - Kevin On Wed, Aug 22, 2018 at 12:04 PM, Lee <ler...@gmail.com> wrote: > Validating input is good & rejecting invalid data is the way to go.. > but has the Internet moved on and check-names is now too restrictive? > > I have this bit in named.conf > check-names response fail; > # restrict the character set and syntax of domain names > # The rules for legal hostnames and mail domains are derived from > RFC 952 and RFC 821 as modified by RFC 1123. > > which seems to be why I can't resolve www.newegg.com but 1.1.1.1 and > 8.8.8.8 can > > C:\Users\Lee>dig www.newegg.com. > > ; <<>> DiG 9.11.4 <<>> www.newegg.com. > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43232 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 97fd73f55fd163f250da7a315b7d7e314d7b33f3eab3f468 (good) > ;; QUESTION SECTION: > ;www.newegg.com. IN A > > ;; Query time: 62 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Aug 22 11:16:01 Eastern Daylight Time 2018 > ;; MSG SIZE rcvd: 71 > > and this is what's logged > security: error: client @000002112790F990 127.0.0.1#50079 > (www.newegg.com): check-names failure > san_ssl-images.newegg.com.edgekey.net/A/IN > > > 8.8.8.8 and 1.1.1.1 don't have a problem with "_" in the name: > > C:\Users\Lee>dig www.newegg.com. @8.8.8.8 > > ; <<>> DiG 9.11.4 <<>> www.newegg.com. @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 681 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.newegg.com. IN A > > ;; ANSWER SECTION: > www.newegg.com. 215 IN CNAME > san_ssl-images.newegg.com.edgekey.net. > san_ssl-images.newegg.com.edgekey.net. 3977 IN CNAME > e5638.g.akamaiedge.net. > e5638.g.akamaiedge.net. 19 IN A 23.46.201.81 > > ;; Query time: 15 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Wed Aug 22 11:16:16 Eastern Daylight Time 2018 > ;; MSG SIZE rcvd: 143 > > C:\Users\Lee>dig www.newegg.com. @8.8.8.8 > > ; <<>> DiG 9.11.4 <<>> www.newegg.com. @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 681 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;www.newegg.com. IN A > > ;; ANSWER SECTION: > www.newegg.com. 215 IN CNAME > san_ssl-images.newegg.com.edgekey.net. > san_ssl-images.newegg.com.edgekey.net. 3977 IN CNAME > e5638.g.akamaiedge.net. > e5638.g.akamaiedge.net. 19 IN A 23.46.201.81 > > ;; Query time: 15 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Wed Aug 22 11:16:16 Eastern Daylight Time 2018 > ;; MSG SIZE rcvd: 143 > > > Thanks > Lee > _______________________________________________ > 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 >
_______________________________________________ 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