On 8/22/18, Darcy, Kevin <kevin.da...@fcagroup.com> wrote: > 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.
Is there an RFC that says a CNAME can't point to another CNAME? I couldn't find anything like that, so I kind of like Amazon's argument that Since a CNAME record is a domain name, and is not necessarily a hostname, a CNAME may contain underscores. https://forums.aws.amazon.com/thread.jspa?start=40&threadID=100022 which would mean that bind's check-names code is wrong. > 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). But further on down in RFC 1034 it explicitly allows CNAME chaining: Domain names in RRs which point at another name should always point at the primary name and not the alias. This avoids extra indirections in accessing information. . . . Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error. So CNAME chaining seems to be more of a "you're being inefficient" than violating a standard - right? > Now, I don't really have a fundamental problem with Akamai, as a company; Just as I don't have a fundamental problem with newegg :) But they're the first site I couldn't get to because I have check-names enabled and I'm not inclined to turn it off just for them.. there's plenty of other on-line stores that I can get to. Thanks, Lee > > > - 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