メインコンテンツまでスキップ

4. 名前サーバー (NAME SERVERS)

4.1. はじめに (Introduction)​

名前サーバーは、ドメインデータベースを構成する情報のリポジトリです。データベースは、ゾーン (zones) と呼ばれるセクションに分割され、名前サーバー間で分散されます。名前サーバーにはいくつかのオプション機能とデータソースがありますが、名前サーバーの本質的なタスクは、そのゾーン内のデータを使用してクエリに応答することです。設計上、名前サーバーは簡単な方法でクエリに応答できます。応答は常にローカルデータのみを使用して生成でき、質問への回答または目的の情報により「近い」他の名前サーバーへの参照のいずれかが含まれます。

特定のゾーンは、ホストまたは通信リンクの障害にもかかわらず可用性を確保するために、複数の名前サーバーから利用可能になります。管理上の命令により、すべてのゾーンは少なくとも2つのサーバーで利用可能である必要があり、多くのゾーンはそれ以上の冗長性を持っています。

特定の名前サーバーは通常、1つ以上のゾーンをサポートしますが、これによりドメインツリーの小さなセクションに関する権威情報のみが提供されます。また、ツリーの他の部分に関するキャッシュされた非権威データも持っている場合があります。名前サーバーは、応答が権威データからのものかどうかを要求者が判断できるように、クエリへの応答をマークします。

4.2. データベースがゾーンに分割される方法 (How the database is divided into zones)​

ドメインデータベースは、クラスとノード間の名前空間での「カット (cuts)」によって2つの方法でパーティション化されます。

クラスパーティショニング (Class partitioning)​

クラスパーティションは単純です。任意のクラスのデータベースは、他のすべてのクラスとは別に編成、委任、および保守されます。慣例により、名前空間はすべてのクラスで同じであるため、個別のクラスは並列名前空間ツリーの配列と考えることができます。これらの異なる並列クラスのノードに添付されるデータは異なることに注意してください。新しいクラスを作成する最も一般的な理由は、既存のタイプの新しいデータ形式の必要性、または既存の名前空間の個別に管理されるバージョンの要望です。

ゾーンカット (Zone cuts)​

クラス内では、任意の2つの隣接するノード間で名前空間に「カット」を作成できます。すべてのカットが作成された後、接続された名前空間の各グループは個別のゾーンです。ゾーンは、接続された領域内のすべての名前に対して権威的であると言われます。名前空間の「カット」は、クラスごとに異なる場所にある場合があり、名前サーバーが異なる場合などがあることに注意してください。

これらのルールは、すべてのゾーンに少なくとも1つのノード、したがってドメイン名があり、そのために権威的であり、特定のゾーン内のすべてのノードが接続されていることを意味します。ツリー構造が与えられると、すべてのゾーンには、ゾーン内の他のどのノードよりもルートに近い最高ノードがあります。このノードの名前は、ゾーンを識別するためによく使用されます。

各ドメイン名が個別のゾーンにあるように、またはすべてのノードが単一のゾーンにあるように名前空間をパーティション化することは可能ですが、特に有用ではありません。代わりに、特定の組織がサブツリーの制御を引き継ぎたいポイントでデータベースがパーティション化されます。組織が独自のゾーンを制御すると、ゾーン内のデータを一方的に変更したり、ゾーンに接続された新しいツリーセクションを成長させたり、既存のノードを削除したり、ゾーンの下に新しいサブゾーンを委任したりできます。

組織に下部構造がある場合、名前空間制御のネストされた委任を実現するために、さらに内部パーティションを作成したい場合があります。場合によっては、このような分割は純粋にデータベースのメンテナンスをより便利にするために行われます。

4.2.1. 技術的考慮事項 (Technical considerations)​

ゾーンを記述するデータには4つの主要な部分があります:

  • 権威データ (Authoritative data): ゾーン内のすべてのノードの権威データ。
  • ゾーンの最上位ノードを定義するデータ: 権威データの一部と考えることができます。
  • 委任されたサブゾーンを記述するデータ: つまり、ゾーンの下部周辺のカット。
  • サブゾーンの名前サーバーへのアクセスを可能にするデータ: 「グルー (glue)」データと呼ばれることもあります。

これらのデータはすべてRRの形式で表現されるため、ゾーンはRRのセットで完全に記述できます。ゾーン全体は、一連のメッセージで運ばれるRRを転送するか、マスターファイル（RRのテキスト表現）をFTPすることにより、名前サーバー間で転送できます。

権威データ (Authoritative data)​

ゾーンの権威データは、ゾーンの最上位ノードからリーフノードまたはゾーンの下端周辺のカットより上のノードまでの、すべてのノードに添付されたすべてのRRです。

論理的には権威データの一部ですが、ゾーンの最上位ノードを記述するRRは、ゾーンの管理にとって特に重要です。これらのRRは2つのタイプです: ゾーンのすべてのサーバーをRRごとに1つリストする名前サーバーRR、およびゾーン管理パラメータを記述する単一のSOA RRです。

委任データ (Delegation data)​

ゾーンの下部周辺のカットを記述するRRは、サブゾーンのサーバーに名前を付けるNS RRです。カットはノード間にあるため、これらのRRはゾーンの権威データの一部ではなく、サブゾーンの最上位ノードの対応するRRと正確に同じである必要があります。名前サーバーは常にゾーン境界に関連付けられているため、NS RRは何らかのゾーンの最上位ノードであるノードでのみ見つかります。ゾーンを構成するデータでは、NS RRはゾーンの最上位ノード（権威的）とゾーンの下部周辺のカット（非権威的）で見つかりますが、その間では決して見つかりません。

グルーデータ (Glue data)​

ゾーン構造の目標の1つは、任意のゾーンがサブゾーンの名前サーバーとの通信を設定するために必要なすべてのデータを持つことです。つまり、親ゾーンには子ゾーンのサーバーにアクセスするために必要なすべての情報があります。サブゾーンのサーバーに名前を付けるNS RRは、サーバーに名前を付けますが、アドレスを提供しないため、このタスクには十分でないことがよくあります。特に、名前サーバーの名前自体がサブゾーンにある場合、名前サーバーのアドレスを学習するには、学習したいアドレスを使用してサーバーに連絡する必要があるという状況に直面する可能性があります。この問題を解決するために、ゾーンには権威データの一部ではない「グルー」RRが含まれており、サーバーのアドレスRRです。これらのRRは、名前サーバーの名前がカットの「下」にある場合にのみ必要であり、参照応答の一部としてのみ使用されます。

4.2.2. 管理上の考慮事項 (Administrative considerations)​

ある組織が独自のドメインを制御したい場合、最初のステップは適切な親ゾーンを識別し、親ゾーンの所有者に制御の委任に同意してもらうことです。ツリーのどこでこれを実行できるかについて特定の技術的制約はありませんが、[RFC-1032] で最上位組織を扱う管理上のグループ化がいくつか説明されており、中間レベルのゾーンは独自のルールを自由に作成できます。たとえば、ある大学は単一のゾーンを使用することを選択する場合がありますが、別の大学は個々の部門または学校専用のサブゾーンによって編成することを選択する場合があります。[RFC-1033] は利用可能なDNSソフトウェアをカタログ化し、管理手順について説明しています。

新しいサブゾーンの適切な名前が選択されたら、新しい所有者は冗長な名前サーバーサポートを示す必要があります。ゾーンのサーバーは、そのドメインに名前を持つホストに存在する必要はないことに注意してください。多くの場合、ゾーンは、ゾーンを管理する同じ組織によって制御される物理施設内にあるよりも、サーバーが広く分散されている場合、インターネット全体により広くアクセスできます。たとえば、現在のDNSでは、英国またはUKドメインの名前サーバーの1つが米国で見つかります。これにより、米国のホストは限られた大西洋横断帯域幅を使用せずにUKデータを取得できます。

最後のインストールステップとして、委任を有効にするために必要な委任NS RRとグルーRRを親ゾーンに追加する必要があります。両方のゾーンの管理者は、カットの両側をマークするNSおよびグルーRRが一貫しており、そのままであることを確認する必要があります。

4.3. 名前サーバーの内部構造 (Name server internals)​

4.3.1. クエリと応答 (Queries and responses)​

名前サーバーの主な活動は、標準クエリに応答することです。クエリとその応答の両方は、[RFC-1035] で説明されている標準メッセージ形式で運ばれます。クエリには、目的の情報のタイプとクラス、および関心のある名前を記述するQTYPE、QCLASS、およびQNAMEが含まれています。

名前サーバーがクエリに応答する方法は、再帰モードで動作しているかどうかによって異なります:

  • 非再帰モード (Non-recursive mode): サーバーの最も単純なモードは非再帰です。これは、ローカル情報のみを使用してクエリに応答できるためです。応答には、エラー、回答、または回答により「近い」他のサーバーへの参照が含まれます。すべての名前サーバーは非再帰クエリを実装する必要があります。

  • 再帰モード (Recursive mode): クライアントにとって最も単純なモードは再帰です。このモードでは、名前サーバーがリゾルバーの役割を果たし、エラーまたは回答を返しますが、参照は返しません。このサービスは名前サーバーではオプションであり、名前サーバーは再帰モードを使用できるクライアントを制限することもできます。

再帰サービスをいつ使用するか (When to use recursive service)​

再帰サービスは、いくつかの状況で役立ちます:

  • 質問への直接的な回答以外を使用する能力を欠く、比較的単純な要求者。
  • プロトコルまたは他の境界を越える必要があり、仲介者として機能できるサーバーに送信できる要求。
  • キャッシュを各クライアントの個別のキャッシュではなく集中させたいネットワーク。

非再帰サービスは、要求者が参照を追跡でき、将来の要求に役立つ情報に関心がある場合に適切です。

再帰ネゴシエーション (Recursion negotiation)​

再帰モードの使用は、クライアントと名前サーバーの両方がその使用に同意する場合に限定されます。合意は、クエリおよび応答メッセージの2つのビットを使用してネゴシエートされます:

  • 再帰利用可能 (RA) ビット (The recursion available bit): すべての応答で名前サーバーによって設定またはクリアされます。このビットは、クライアントが再帰サービスを要求したかどうかに関係なく、名前サーバーがクライアントに再帰サービスを提供する意思がある場合にtrueです。つまり、RAは使用ではなく可用性を通知します。

  • クエリには再帰希望 (RD) ビット (Queries contain a recursion desired bit) が含まれています。このビットは、要求者がこのクエリに対して再帰サービスを望むかどうかを指定します。クライアントは任意の名前サーバーから再帰サービスを要求できますが、以前にRAを送信したサーバー、またはプライベート契約やDNSプロトコル外の他の手段を通じてサービスを提供することに同意したサーバーからのみ受信することに依存する必要があります。

再帰モードは、RDが設定されたクエリが再帰サービスを提供する意思のあるサーバーに到着したときに発生します。クライアントは、応答でRAとRDの両方が設定されていることを確認することにより、再帰モードが使用されたことを確認できます。名前サーバーは、RDで要求されない限り再帰サービスを実行すべきではないことに注意してください。これは名前サーバーとそのデータベースのトラブルシューティングを妨げるためです。

応答タイプ (Response types)​

再帰サービスが要求され利用可能な場合、クエリへの再帰応答は次のいずれかになります:

  • クエリへの回答。回答への途中で遭遇したエイリアスを指定する1つ以上のCNAME RRで前置される場合があります。
  • 名前が存在しないことを示す名前エラー。これには、元のクエリ名が存在しない名前のエイリアスであることを示すCNAME RRが含まれる場合があります。
  • 一時的なエラー表示。

再帰サービスが要求されていないか利用できない場合、非再帰応答は次のいずれかになります:

  • 名前が存在しないことを示す権威的な名前エラー。
  • 一時的なエラー表示。
  • 次の組み合わせ:
    • 質問に答えるRR、データがゾーンからのものかキャッシュされているかの表示とともに。
    • 応答を送信するサーバーよりも名前に近い祖先であるゾーンを持つ名前サーバーへの参照。
    • 名前サーバーが要求者に役立つと考えるRR。

4.3.2. アルゴリズム (Algorithm)​

名前サーバーが使用する実際のアルゴリズムは、RRを格納するために使用されるローカルOSとデータ構造に依存します。次のアルゴリズムは、RRがゾーンごとに1つ、キャッシュ用に別のツリー構造に編成されていることを前提としています:

  1. 応答で再帰利用可能の値を設定またはクリア: 名前サーバーが再帰サービスを提供する意思があるかどうかに応じて。再帰サービスが利用可能でクエリのRDビットを介して要求された場合は、ステップ5に進みます。それ以外の場合はステップ2に進みます。

  2. 利用可能なゾーンを検索: QNAMEに最も近い祖先であるゾーンを検索します。そのようなゾーンが見つかった場合はステップ3に進み、それ以外の場合はステップ4に進みます。

  3. ゾーン内でラベルごとに一致を開始: 一致プロセスはいくつかの方法で終了できます:

    a. QNAMEの全体が一致した場合、ノードが見つかりました。

    ノードのデータがCNAMEで、QTYPEがCNAMEと一致しない場合、CNAME RRを応答の回答セクションにコピーし、QNAMEをCNAME RR内の正規名に変更し、ステップ1に戻ります。

    それ以外の場合は、QTYPEに一致するすべてのRRを回答セクションにコピーし、ステップ6に進みます。

    b. 一致により権威データから外れる場合、参照があります。これは、ゾーンの下端に沿ったカットをマークするNS RRを持つノードに遭遇したときに発生します。

    サブゾーンのNS RRを応答の権威セクションにコピーします。利用可能なアドレスを追加セクションに配置し、権威データまたはキャッシュからアドレスが利用できない場合はグルーRRを使用します。ステップ4に進みます。

    c. あるラベルで一致が不可能な場合（つまり、対応するラベルが存在しない場合）、"*" ラベルが存在するかどうかを確認します。

    "*" ラベルが存在しない場合、探している名前がクエリの元のQNAMEか、CNAMEに従った名前かを確認します。名前が元の場合、応答に権威的な名前エラーを設定して終了します。それ以外の場合は終了します。

    "" ラベルが存在する場合、そのノードのRRをQTYPEと照合します。一致するものがある場合は、回答セクションにコピーしますが、RRの所有者を "" ラベルを持つノードではなくQNAMEに設定します。ステップ6に進みます。

  4. キャッシュ内で一致を開始: QNAMEがキャッシュで見つかった場合、QTYPEに一致する添付されたすべてのRRを回答セクションにコピーします。権威データからの委任がない場合は、キャッシュから最適なものを探し、権威セクションに配置します。ステップ6に進みます。

  5. ローカルリゾルバーを使用: またはそのアルゴリズムのコピー（このメモのリゾルバーセクションを参照）を使用してクエリに応答します。中間CNAMEを含む結果を応答の回答セクションに格納します。

  6. ローカルデータのみを使用: クエリの追加セクションに役立つ可能性のある他のRRを追加しようとします。終了します。

4.3.3. ワイルドカード (Wildcards)​

前のアルゴリズムでは、"*" ラベルで始まる所有者名を持つRRに特別な処理が与えられました。このようなRRはワイルドカードと呼ばれます。ワイルドカードRRは、RRを合成するための指示と考えることができます。適切な条件が満たされると、名前サーバーは、クエリ名に等しい所有者名とワイルドカードRRから取得した内容を持つRRを作成します。

この機能は、インターネットから他のメールシステムにメールを転送するために使用されるゾーンを作成するために最も頻繁に使用されます。一般的なアイデアは、クエリでサーバーに提示されるそのゾーン内の任意の名前は、明示的な証拠が反対に存在しない限り、特定のプロパティを持って存在すると想定されるということです。ここでのゾーンという用語の使用は、ドメインではなく意図的であることに注意してください。このようなデフォルトはゾーン境界を越えて伝播しませんが、サブゾーンは同様のデフォルトを設定することにより、その外観を実現することを選択できます。

ワイルドカードの構文とセマンティクス (Wildcard syntax and semantics)​

ワイルドカードRRの内容は、RRの通常のルールと形式に従います。ゾーン内のワイルドカードには、一致するクエリ名を制御する所有者名があります。ワイルドカードRRの所有者名は *.<anydomain> の形式です。ここで <anydomain> は任意のドメイン名です。<anydomain> には他の * ラベルを含めるべきではなく、ゾーンの権威データに含まれている必要があります。ワイルドカードは <anydomain> の子孫に潜在的に適用されますが、<anydomain> 自体には適用されません。これを見る別の方法は、"*" ラベルが常に少なくとも1つの完全なラベルに一致し、時にはそれ以上に一致するが、常に完全なラベルに一致するということです。

ワイルドカードが適用されない場合 (When wildcards do not apply)​

ワイルドカードRRは次の場合には適用されません:

  • クエリが別のゾーンにある場合: つまり、委任はワイルドカードのデフォルトをキャンセルします。

  • クエリ名またはワイルドカードドメインとクエリ名の間の名前が存在することが知られている場合: たとえば、ワイルドカードRRの所有者名が "*.X" で、ゾーンにB.Xに添付されたRRも含まれている場合、ワイルドカードは名前Z.Xのクエリに適用されます（Z.Xの明示的な情報がないと仮定）が、B.X、A.B.X、またはXには適用されません。

クエリ名に表示される * ラベルには特別な効果はありませんが、権威ゾーンでワイルドカードをテストするために使用できます。このようなクエリは、所有者名に * を含むRRを含む応答を取得する唯一の方法です。このようなクエリの結果はキャッシュすべきではありません。

ワイルドカードRRの内容は、RRを合成するために使用される際に変更されないことに注意してください。

ワイルドカードの例 (Wildcard example)​

ワイルドカードRRの使用を説明するために、非IP/TCPの大規模なネットワークを持つ大企業がメールゲートウェイを作成したいとします。会社がX.COMと呼ばれ、IP/TCP対応のゲートウェイマシンがA.X.COMと呼ばれる場合、次のRRがCOMゾーンに入力される可能性があります:

X.COM           MX      10      A.X.COM

*.X.COM         MX      10      A.X.COM

A.X.COM         A       1.2.3.4
A.X.COM         MX      10      A.X.COM

*.A.X.COM       MX      10      A.X.COM

これにより、X.COMで終わる任意のドメイン名のMXクエリは、A.X.COMを指すMX RRを返します。*.X.COMでのワイルドカードの効果は、A.X.COMの明示的なデータによってA.X.COMサブツリーで阻害されるため、2つのワイルドカードRRが必要です。また、X.COMおよびA.X.COMでの明示的なMXデータが必要であり、上記のRRのいずれもXX.COMのクエリ名に一致しないことに注意してください。

4.3.4. 否定応答キャッシング (Negative response caching) (オプション)​

DNSは、名前サーバーがTTLで否定結果を配布し、リゾルバーがキャッシュできるオプションのサービスを提供します。たとえば、名前サーバーは名前エラー表示とともにTTLを配布でき、そのような情報を受信したリゾルバーは、権威データを参照せずにTTL期間中名前が存在しないと想定することができます。同様に、リゾルバーは複数のタイプに一致するQTYPEでクエリを作成し、一部のタイプが存在しないという事実をキャッシュできます。

この機能は、検索リストを使用する命名ショートハンドを実装するシステムで特に重要です。これは、検索リストの終わり近くのサフィックスを必要とする人気のあるショートハンドが使用されるたびに複数の名前エラーを生成するためです。

実装方法 (Implementation method)​

方法は、名前サーバーが応答が権威的である場合、応答の追加セクションにSOA RRを追加できることです。SOAは、回答セクションの権威データのソースであったゾーンのSOA、または該当する場合は名前エラーのSOAである必要があります。SOAのMINIMUMフィールドは、否定結果をキャッシュできる期間を制御します。

場合によっては、回答セクションに複数の所有者名が含まれる場合があることに注意してください。この場合、SOAメカニズムは、このセクションで唯一の権威データであるQNAMEに一致するデータにのみ使用する必要があります。

名前サーバーとリゾルバーは、非権威応答の追加セクションにSOAを追加しようとしたり、権威応答で直接述べられていない結果を推測しようとしたりすべきではありません。これにはいくつかの理由があります。キャッシュされた情報は通常、RRとそのゾーン名を照合するのに十分ではない、SOA RRは直接SOAクエリによりキャッシュされる可能性がある、名前サーバーは権威セクションでSOAを出力する必要がないなどです。

この機能はオプションですが、洗練されたバージョンが将来標準プロトコルの一部になることが期待されています。名前サーバーはすべての権威応答でSOA RRを追加する必要はなく、リゾルバーは否定結果をキャッシュする必要もありません。両方が推奨されます。すべてのリゾルバーと再帰名前サーバーは、応答にSOA RRが存在する場合、少なくともそれを無視できる必要があります。

この機能を使用するいくつかの実験も提案されています。アイデアは、キャッシュされたデータが特定のゾーンから来ることが知られている場合、ゾーンのSOAの権威コピーが取得され、データがキャッシュされてからゾーンのSERIALが変更されていない場合、キャッシュされたデータのTTLがより小さい場合はゾーンのMINIMUM値にリセットできるということです。この使用法は計画目的でのみ言及されており、まだ推奨されていません。

4.3.5. ゾーンのメンテナンスと転送 (Zone maintenance and transfers)​

ゾーン管理者の仕事の一部は、ゾーンに対して権威的なすべての名前サーバーでゾーンを維持することです。避けられない変更が行われた場合、それらをすべての名前サーバーに配布する必要があります。この配布はFTPまたは他のアドホックな手順を使用して達成できますが、推奨される方法はDNSプロトコルのゾーン転送部分です。

ゾーン転送モデル (Zone transfer model)​

自動ゾーン転送または更新の一般的なモデルは、名前サーバーの1つがゾーンのマスターまたはプライマリであることです。変更はプライマリで調整され、通常はゾーンのマスターファイルを編集することによって行われます。編集後、管理者はマスターサーバーに新しいゾーンをロードするよう信号を送ります。ゾーンの他の非マスターまたはセカンダリサーバーは、定期的に変更をチェックし（選択可能な間隔で）、変更が行われたときに新しいゾーンコピーを取得します。

SERIALによる変更検出 (Change detection via SERIAL)​

変更を検出するために、セカンダリはゾーンのSOAのSERIALフィールドをチェックするだけです。他の変更に加えて、ゾーンに変更が行われるたびに、ゾーンのSOAのSERIALフィールドは常に進められます。前進は単純なインクリメントであるか、マスターファイルの書き込み日時などに基づくことができます。目的は、シリアル番号を比較することにより、ゾーンの2つのコピーのどちらがより最近のものかを判断できるようにすることです。シリアル番号の前進と比較はシーケンス空間演算を使用するため、ゾーンを更新できる速度には理論的な制限があります。基本的には、古いコピーがシリアル番号が32ビット範囲の半分をカバーする前に消滅する必要があります。実際には、唯一の懸念は、比較操作が最も正の32ビット数と最も負の32ビット数の間の境界周辺の比較を適切に処理することです。

ゾーン転送のためのSOAパラメータ (SOA parameters for zone transfer)​

セカンダリサーバーの定期的なポーリングは、ゾーンのSOA RRのパラメータによって制御され、最小許容ポーリング間隔を設定します。パラメータはREFRESH、RETRY、およびEXPIREと呼ばれます。新しいゾーンがセカンダリにロードされるたびに、セカンダリは新しいシリアルをプライマリにチェックする前にREFRESH秒待機します。このチェックが完了できない場合、新しいチェックがRETRY秒ごとに開始されます。チェックは、ゾーンのSOA RRに対するプライマリへの単純なクエリです。セカンダリのゾーンコピーのシリアルフィールドがプライマリによって返されたシリアルと等しい場合、変更は発生しておらず、REFRESH間隔待機が再開されます。セカンダリがEXPIRE間隔の間シリアルチェックを実行できないことを見つけた場合、ゾーンのコピーが古くなっていると想定し、破棄する必要があります。

AXFRゾーン転送 (AXFR zone transfer)​

ポーリングによりゾーンが変更されたことが示された場合、セカンダリサーバーはゾーンのAXFR要求を介してゾーン転送を要求する必要があります。AXFRは拒否などのエラーを引き起こす可能性がありますが、通常は一連の応答メッセージで応答されます。最初と最後のメッセージには、ゾーンの最上位の権威ノードのデータが含まれている必要があります。中間メッセージは、権威および非権威RRの両方を含む、ゾーンからの他のすべてのRRを運びます。メッセージのストリームにより、セカンダリはゾーンのコピーを構築できます。正確性が不可欠であるため、AXFR要求にはTCPまたは他の信頼できるプロトコルを使用する必要があります。

各セカンダリサーバーは、マスターに対して次の操作を実行する必要がありますが、他のセカンダリサーバーに対してこれらの操作をオプションで実行することもできます。この戦略は、プライマリがホストのダウンタイムやネットワークの問題により利用できない場合、またはセカンダリサーバーがプライマリよりも「中間」セカンダリへのネットワークアクセスが優れている場合に、転送プロセスを改善できます。

に最終更新