check-names response fail;

Discussion:

Lee

2018-08-22 16:04:57 UTC

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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Darcy, Kevin

2018-08-22 16:48:11 UTC

Permalink

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

Post by Lee
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
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43232
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 97fd73f55fd163f250da7a315b7d7e314d7b33f3eab3f468 (good)
;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
(www.newegg.com): check-names failure
san_ssl-images.newegg.com.edgekey.net/A/IN
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 681
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 512
;www.newegg.com. IN A
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
;; global options: +cmd
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 681
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags:; udp: 512
;www.newegg.com. IN A
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
https://lists.isc.org/mailman/listinfo/bind-users

Lee

2018-08-22 23:13:24 UTC

Permalink

Post by Darcy, Kevin
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.

Post by Darcy, Kevin
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?

Post by Darcy, Kevin
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

Post by Darcy, Kevin
- Kevin

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
bind-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Continue reading on narkive:

Search results for 'check-names response fail;' (Questions and Answers)

replies

Aetheists say they don't get upset, but they do, don't they?

started 2006-07-04 07:21:53 UTC

religion & spirituality

replies

Is this a scam response from craigslist?

started 2010-06-20 15:23:48 UTC

security

replies

response for smog check...somebody help me pls!!!?