ユーザーにサブドメインを使用するドメインがあります。例:
user1.example.com
他の公式サブドメインとユーザー サブドメインを区別するために、すべての場合に「at」を予約しました。たとえば、公式サブドメインには次のようなものがあります。
api.at.example.com, releases.at.example.com, support.at.example.com
これまでに 2 回、フィッシングの誤検出によるブロックに遭遇しました。これまでのところ、Google と Cisco によるものです。私のサイトが「api.at」または「releases.at」になりすまそうとしているのではないかと示唆しているようです。
悪意のあるアクティビティの兆候がないサブドメインを、単に一般的な名前に基づいてブロックするサービスは非常に迷惑です。特に迷惑なのは、ユーザーがバイパスするオプションがない状態で fetch/xhr リクエストをブロックする Cisco です。少なくとも Google は、ブラウザーでドメインをページとしてアクセスした場合にのみ、fetch/xhr をブロックします。
これがどの程度一般的なのか知りたいです。この問題を回避するために、代わりにいくつかの第 1 レベルのサブドメインを予約することを検討していますが (例api.example.com)、サービスがネストされたすべてのサブドメインを効果的にブロックするのはばかげているように思われます。これが一般的でない場合は、問題のあるサービスにサポート チケットを送信してみるかもしれません。
(これは、以前の所有者がおらず、悪意のあるコンテンツが一切ない、まったく新しいドメインです。アプリ全体を自分で作成したためです)
答え1
はい、私はそのような過剰なブロックで広範囲にわたる問題を引き起こすのは無謀であることに同意しますが、これは単一のエンティティに限定されないこれを個別に修正できるようになります。
私は管理しているデスクトップ システムに同様のブロック ルールをインストールし、大手の商業組織がデバイス フリート全体にそのようなブロックを実施していることを確認しました。私のルールは、少なくとも所有および関連するブランド名を含むか類似するドメインにのみ適用されます。他の企業は「URL 脅威分類」を決定するために「機械学習」を使用していると主張していますが、これはシスコで経験したことと同じ結果になる可能性がさらに高いように思われます。
この種の検出は間違いなく一般的なメールのコンテキスト- 許可されていないメールを中継していることが判明した場合、即座にスパム送信元として分類されることを覚悟しておく必要があります<brandname>.<tld>.<otherdomain>.<tld>。
詐欺師に利用されないように、顧客を審査し監視することが求められますbankofamerica.com.yourdomain.example。ドメインが安全なデフォルトを選択しなかったように見える場合、特に敏感なヒューリスティックの問題が発生する可能性があります。人気のあるccTLDは避ける(例: .at)およびuTLD（例：.com）使用するラベル真ん中に長いドメイン名の場合。
ユーザーに提供するサービスの種類によっては、そのドメインを持つことが適切である場合もあります。パブリックサフィックスリストに追加されましたそうでない場合でも、関連ドキュメントを読んでください。他のサービスでも使用されているドメインの下にユーザー コンテンツをホストすることがそもそも良いアイデアであるかどうかを判断するのに役立つ場合があります (ヒント: 最近のブラウザーは複雑です)。