DNS: Tên miền con yêu cầu cả bản ghi MX và CNAME


17

Hãy để chúng tôi nói rằng chúng tôi sở hữu khu vực mywebservice.com.

Tôi muốn mỗi khách hàng của mình có được tên miền phụ của riêng họ, chẳng hạn như customer.mywebservice.com.

customer.mywebservice.com cần phải là một CNAME cho một máy chủ ngoại vi nhất định. Vì trang web đó quản lý thiết bị của riêng mình và có thể thay đổi địa chỉ tại bất kỳ thời điểm nào, nên CNAME là một yêu cầu.

Mọi người cũng cần có thể gửi email đến inbox@customer.mywebservice.com, nơi sẽ yêu cầu một bản ghi MX đơn giản.

Tuy nhiên, và đây là nơi tôi muốn có một số hướng dẫn:

Theo RFC 1034 :

If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.

Tôi cũng đã xác minh rằng máy chủ DNS của tôi sẽ từ chối cung cấp mọi thứ trừ CNAME cho các máy chủ sử dụng chúng.

Vì vậy, dường như tôi có thể có một tình huống thua cuộc. Nếu tôi muốn sử dụng bản ghi MX, tôi cần sử dụng A thay vì CNAME.

Bất cứ ai có thể nghĩ về bất kỳ cách giải quyết? Cảm ơn!

Câu trả lời:


20

Thật không may, những gì bạn đang chạy vào là một hạn chế của đặc tả DNS. Có bản ghi MX cho cùng tên máy chủ được xác định là bản ghi CNAME sẽ thất bại trong hầu hết các triển khai máy chủ DNS. Một số máy chủ DNS cũ hơn sẽ cho phép điều này, nhưng chúng hầu như đã được loại bỏ theo hướng có lợi cho các triển khai mới hơn, an toàn hơn.

Thay vì sử dụng các bản ghi CNAME, bạn sẽ cần sử dụng các bản ghi 'A' với địa chỉ IP của các trang web của khách hàng thay vì đặt bí danh tên.


Vâng, tôi đoán tôi sẽ phải đối mặt với điều này. Cảm ơn!
Michael Gorsuch

2
Tôi cũng cần lưu ý, đối với những người đọc bài này, lý do cho sự hạn chế này là một CNAME được cho là đề cập đến "tên chính tắc" cho máy chủ được tra cứu. Ví dụ: nếu bạn có máy chủ, x2.example.com là bản ghi CNAME trỏ đến x1.example.com, thì bất kỳ trình phân giải nào đang tìm kiếm x2 sẽ thấy CNAME, thay thế bất cứ điều gì nó làm cho x2 bằng x1 và bắt đầu lại . Nếu bạn có bản ghi MX cho x2 ngoài CNAME, thì nếu x1 cũng có MX, có khả năng chúng sẽ khác nhau, điều không mong muốn, vì vậy chúng chỉ đơn giản là không cho phép.
Justin Scott

18

Sau rất nhiều công việc và nghiên cứu ở đây, tôi đã tìm thấy một giải pháp chấp nhận được. Đầu tiên, điều quan trọng là tất cả chúng ta đều tuân theo RFC. Tôi đã vá máy chủ DNS của mình để vi phạm RFC và tôi phát hiện ra rằng một số máy chủ DNS lớn khác sẽ không tôn trọng sự thay đổi.

Động thái thích hợp là đặt MX trên máy chủ lưu trữ mà CNAME trỏ tới. Vì vậy, nếu customer.mywebservice.com là một CNAME cho bản ghi loadbalancer.mywebservice.com, thì cũng nên xây dựng bản ghi MX cho loadbalancer.mywebservice.com. Tôi đã xác minh rằng điều này hoạt động với tất cả các bộ giải quyết chính.

Nếu một truy vấn MX được tạo cho khách hàng.mywebservice.com, thư viện trình phân giải sẽ theo CNAME và nhận MX thích hợp cho bản ghi A cuối cùng. Tiếng hoan hô!


4

customer.mywebservice.com cần phải là một CNAME cho một máy chủ ngoại vi nhất định. Vì trang web đó quản lý thiết bị của riêng mình và có thể thay đổi địa chỉ tại bất kỳ thời điểm nào, nên CNAME là một yêu cầu.

Bất cứ ai có thể nghĩ về bất kỳ cách giải quyết? Cảm ơn!

Bạn có một yêu cầu là khách hàng phải có khả năng thay đổi địa chỉ, bạn đã xem xét cho phép khách hàng tự động cập nhật hồ sơ của họ chưa? Với dns động, bạn có thể sử dụng bản ghi A và khách hàng có thể thay đổi bản ghi khi cần. Sẽ mất một chút công việc, nhưng bạn có thể mỗi tên miền phụ riêng lẻ thành một vùng riêng biệt để bạn có thể đảm bảo khách hàng chỉ có thể chạm vào vùng riêng của họ.

Tôi đã không thử nhưng gnudip dường như là một công cụ nguồn mở để tạo điều kiện cập nhật động mà không phải xử lý xác thực và thiết lập nhiều vùng trên máy chủ DNS của bạn.


3

Nếu các bản ghi MX của bạn sẽ giống nhau cho tất cả các bản ghi này, thì bạn có thể thử sử dụng một DNAME để chuyển hướng XYZ.mywebservice.com sang hosting.mywebservice.com. Trong hosting.mywebservice.com thêm các bản ghi MX và A đáng tin cậy của bạn.

Tôi phải nói rằng tôi chưa bao giờ sử dụng các bản ghi DNAME trong sản xuất, nhưng bạn có thể đọc thêm về chúng trong RFC2672 .


Tôi muốn thử sử dụng DNAME với một số tên miền SSL của chúng tôi, nhưng tôi nghe nói vẫn còn vấn đề với các máy chủ DNS cũ hơn, v.v. Điều này có liên quan không? Hoặc DNAME có an toàn để sử dụng trên các máy chủ sản xuất không?
Drybjed

Nếu tôi phải đoán, nhiều ứng dụng không mong đợi các bản ghi DNAME và có thể bị hỏng khi sử dụng chúng. Có phải tất cả các máy chủ thư đều theo dõi DNAME để tra cứu bản ghi MX không? Tôi không biết, nhưng họ nên. Đối với sự cố SSL của bạn, các máy chủ DNS không hiểu DNAME thay vào đó sẽ nhận được tham chiếu CNAME. Tôi sẽ kiểm tra kỹ lưỡng điều này trước khi thực hiện nó.
Doug Luxem

Ứng dụng chắc chắn KHÔNG phải xử lý hồ sơ DNAME! Nó chỉ được thực hiện trong các máy chủ tên.
bortzmeyer

3

RHS của khách hàng.mywebservice.com CNAME có mục MX không?

Nếu vậy, máy chủ thư sẽ sử dụng MX đó để tìm máy chủ thư sử dụng. Hy vọng bạn có thể kiểm soát điều đó.


1

Câu trả lời của Michael Gorsuch phần lớn là chính xác, chuỗi CNAME -> Chuỗi A + MX hoạt động ... chủ yếu . Tuy nhiên, nó kích hoạt một số hành vi xấu trong một số MTA nhất định. Những gì tôi đã tìm thấy chạy giải pháp này ở một mức độ tốt:

  • một số MTA đơn giản sẽ từ chối tìm hồ sơ.
  • những người khác sẽ thay thế không chính xác bản ghi A trong đó CNAME phải là: tức là tôi đã gửi thư đến "joe@foo.example.com", mà CNnam gửi đến web.example.com, có MX của mail.example.com và MTA viết lại tiêu đề phong bì là "Tới: joe@web.example.com".

Vẫn chưa rõ các vấn đề này phổ biến như thế nào (google / hotmail / yahoo / etc tất cả dường như giải quyết vấn đề này một cách chính xác), nhưng chắc chắn họ đã tìm kiếm các giải pháp tốt hơn.


2
Chính xác; hành vi được ghi lại cho các máy chủ SMTP tuân thủ RFC5321 trước tiên là kiểm tra sự tồn tại của bản ghi MX cho miền và nếu thất bại, hãy kiểm tra sự tồn tại của bản ghi A. Hành vi này là lý do thực sự, về mặt kỹ thuật tại sao MX không phải là một CNAME: nó sẽ ngừng giải quyết sau câu trả lời có thể sử dụng đầu tiên.
thích nghi

0

Một giải pháp khả thi và hợp lệ sẽ là tạo một tên máy chủ cơ bản cho tất cả khách hàng của bạn và đặt nó thành bản ghi a và aaaa của máy chủ web ngoài trang web và mx của bạn, sau đó CNAME tất cả tên miền khách hàng của bạn thành tên máy chủ duy nhất đó. Bằng cách đó, bạn sẽ chỉ phải thay đổi một bản ghi khi địa chỉ IP của trang bên ngoài thay đổi.

Đây là cách định giá duy nhất và có thể, vì CNAME là bí danh cho một bộ hồ sơ hoàn chỉnh, không chỉ là a.


-4

MX và CNAME là các bản ghi hoàn toàn riêng biệt - cái đầu tiên xác định máy chủ thư cho tên miền đã cho, thứ hai cung cấp địa chỉ cho tên miền. Điều này sẽ làm việc:

@ IN SOA ns1.mywebservice.com. root.mywebservice.com. (
                        2009060201
                        12h
                        1h
                        1w
                        8 giờ
)

                        NS ns1.mywebservice.com.
                        NS ns2.mywebservice.com.

CNAME khách hàng ngoại vi.host.
khách hàng MX 10 mail.server.

4
Điều đó có thể hoạt động, nhưng nó vi phạm RFC1034 và RFC1219, nói rằng không có bản ghi tài nguyên nào khác có thể có cùng tên với CNAME.
Doug Luxem

Trình nền DNS của tôi là RFC nghiêm ngặt, chỉ đơn giản là từ chối gửi phản hồi cho MX. Tôi tin rằng có một số vấn đề bộ nhớ cache tiềm ẩn ở phía khách hàng nếu chúng ta đặt vấn đề này.
Michael Gorsuch

Daemon DNS nào? Tôi đang sử dụng BIND9, hoạt động với cấu hình đó mà không gặp vấn đề gì. Có lẽ đã đến lúc nâng cấp? Cơ sở hạ tầng lớn, tôi đoán?
Drybjed

Tôi đang sử dụng MyDNS. Đó là một cấu hình khá lớn, và daemon nhỏ này đã được ban phước cho đến thời điểm này. Tôi đang xem xét vá nó, nhưng tôi không quan tâm lắm đến việc xử lý bất kỳ tác dụng phụ nào sinh ra. Nếu nó đi ngược lại với RFC, nó có vẻ như là một ý tưởng tồi.
Michael Gorsuch

@Maciej - chắc chắn, máy chủ thẩm quyền của bạn thể lưu trữ những hồ sơ này. Mặc dù vậy, họ sẽ nhầm lẫn giữa hầu hết các máy chủ đệ quy truy vấn họ.
Alnitak
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.