使用CNAME与修改域名DNS服务器时的Cookie行为差异

场景1：B.org设置CNAME指向A.com #

你的理解完全正确。当B.org通过CNAME解析到A.com时，浏览器访问B.org时地址栏显示的是B.org，但实际连接的是A.com的服务器。此时服务器返回的Cookie：

• 若未指定Set-Cookie头的Domain属性，默认绑定到服务器主机名A.com，对B.org来说属于第三方Cookie；
• 若服务器尝试指定Domain=B.org，浏览器会拒绝该设置——因为服务器的主机名是A.com，与B.org不属于同一域，且CNAME配置不代表服务器拥有B.org的控制权，不符合Cookie的域权限规则。
  因此这种场景下，服务器仅能设置域为A.com的第三方Cookie，无法设置B.org的第一方Cookie。

场景2：B.org的DNS服务器指向A.com的IP #

你的理解正确。当B.org直接解析到A.com的IP时，浏览器地址栏显示B.org，服务器响应时：

• 若Set-Cookie头未指定Domain，默认绑定到B.org，属于第一方Cookie；
• 若明确指定Domain=B.org，同样会被视为B.org的第一方Cookie。
  这种配置下，浏览器会将服务器视为B.org的服务提供者，因此绑定到B.org的Cookie会被当作第一方处理。

额外问题：场景2中访问B.org能否获取A.com的Cookie？ #

不能。根据Cookie的域匹配规则：只有当前页面的域是Cookie域的子集（或完全匹配）时，浏览器才会携带该Cookie。A.com和B.org是相互独立的顶级域下的域名，不存在子集关系，因此访问B.org时，浏览器不会发送A.com的Cookie，服务器也无法获取到。

参考文档 #

• RFC 6265：Cookie的核心标准，第5.1.3节定义了域匹配逻辑，第5.2节说明了Set-Cookie头的处理规则，明确了Cookie的权限与绑定规则。
• Chrome开发者文档（Cookie模块）：解释了现代浏览器对第一方/第三方Cookie的区分、跨域Cookie限制，以及安全策略对Cookie行为的影响。
• MDN Web Docs Cookie指南：详细讲解Cookie的工作原理、域属性的作用，以及不同部署场景下的Cookie行为细节。

内容的提问来源于stack exchange，提问作者cybernetic73