回答:
DNSから解決される名前は大文字と小文字を区別しません。これは混乱を防ぐために重要です。大文字と小文字が区別される場合、.comの8つのバリアント（.com、.Com、.cOm、.COm、.coM、.CoM、.cOM、および.COM）があります。国コードには4つあります。
Pingの名前解決で大文字と小文字が区別される場合、DNSによって実行されていません。
私は仕事でこれをちょうど持っていました。DNS は大文字と小文字を区別しません。...RFCはそれを指定しています。https://tools.ietf.org/html/rfc4343 しかし、小文字である必要があるとは言いません。
そのため、内部ドメイン「t.local」の問題を正しく解決できなかったホストのトラブルシューティングを行うことができました。
p123$ ping p123-db.t.local
PING p123-db.t.local (192.168.106.175) 56(84) bytes of data.
....works ok
p123$ ping P123-dB.T.lOcal
ping: unknown host P123-dB.T.lOcal
なぜ大/小文字混合の問題を解決するのですか？なぜなら、それがtcpdumpがDNSクエリとして示していたのは、それが実行中のソフトウェアが求めていたからです。pgbouncerはその構成で "p123-db"を使用するように構成され、resolv.confは "t.local"の検索ドメインを指定しました。
glibcはケースをランダムに切り替えていたことがわかりました。このプロセスは「0x20パディング」と呼ばれ、2008年に「DNSラベルのビット0x20を使用してトランザクションIDを改善する」http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00で初めて説明されました。
主な目的は、エントロピーを増やして、回答を偽造するのが難しくなるようにすることです。質問のケースは回答のケースと一致する必要があります。
良い議論がここにあります。 https://developers.google.com/speed/public-dns/docs/security?csw=1#randomize_case
それとは別に、powerDNSを内部で実行し、データベースに対して検索を行います。何年もの間、t.localドメインで大文字でホスト名またはFQDNを使用した人はいないため、内部ドメインで大文字と小文字が区別されることに気が付きませんでした。
クエリの一部の調整により修正されましたが、上記のように0x20の大文字と小文字が混在するルックアップが破損していました。
簡単な答え：DNSは大文字と小文字を区別するべきではありませんが、質問と回答は将来的には同一の大文字である必要があります。
ホスト名の解決で大文字と小文字が区別される組み込みSE Linuxデバイスの問題のトラブルシューティングを完了しました。
「ping MYHOST」は127.0.0.1にpingを実行しますが、「ping myhost」は正しいIPアドレスにpingを実行します。
nslookupは大文字と小文字の両方で正しい結果を生成し、DNSサーバーに障害がなかったことを示しています。
ただし、キャッシュを無視するnslookupとは異なり、「getent hosts MYHOST」は「0.0.0.0」を出力し、「getent hosts myhost」は正しいIPアドレスを出力します。
したがって、nscdは大文字と小文字を区別するようです。「nscd -i hosts」を呼び出してキャッシュをクリアすると、問題が修正されました。
（大文字の）MYHOSTは、DNSエントリが作成される前にMYHOSTへの接続を確立しようとするプロセスが原因で、0.0.0.0でキャッシュされました。これは、リモートデバイスがDHCP割り当てを取得するときに発生します。
BillThorが述べたように、DNSまたはnetbiosの解決レベルでは大文字と小文字は区別されません。
さまざまなOSでも、異なるケーシングの問題は発生しません。
ただし、アプリケーションはそれらを認識している場合があります。たとえば、さまざまな環境のWebプラットフォームは、大文字と小文字の区別を確認できます。検索エンジン最適化（SEO）の理由から、異なる大文字小文字とリダイレクトを監視することが一般的になりました。それはすべてアプリケーション次第ですので、そこでの答えはそれが異なるということです。
「ほとんどの部分」では、ホスト名はアプリケーションレベルでも大文字と小文字を区別しません。