check-names response fail;

Wed Aug 22 23:13:24 UTC 2018

On 8/22/18, Darcy, Kevin <kevin.darcy at 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 <ler762 at 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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>