[GH-ISSUE #1098] Add support for DNS DNAME records. #603

New issue

Open

opened 2026-03-15 23:23:48 +03:00 by kerem · 3 comments

kerem commented

2026-03-15 23:23:48 +03:00

Owner

Originally created by @DevQps on GitHub (May 8, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1098

Description

Currently the DNS DNAME record type is not implemented. RFC6672 describes this DNS record. It has the DNS record type of 39.

Originally created by @DevQps on GitHub (May 8, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1098 # Description Currently the DNS DNAME record type is not implemented. RFC6672 describes this DNS record. It has the DNS record type of 39.

kerem added the

enhance

crate:proto

labels

2026-03-15 23:23:48 +03:00

kerem commented

2026-03-15 23:23:59 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 8, 2020):

Is this for client or server code?

The last time I looked at supporting DNAME in the server I was concerned about the complexity, but since then a few things have changed. One is that we no do interior lookups for names in the server to pickup optional records, and to support ANAME we needed more dynamic lookup support there. So this might be easier now.

If it’s just to support the record type for the client, that should be fairly simple. For the resolver, I’m not sure if there’s any processing that might be required there (like CNAME).

@bluejekyll commented on GitHub (May 8, 2020): Is this for client or server code? The last time I looked at supporting DNAME in the server I was concerned about the complexity, but since then a few things have changed. One is that we no do interior lookups for names in the server to pickup optional records, and to support ANAME we needed more dynamic lookup support there. So this might be easier now. If it’s just to support the record type for the client, that should be fairly simple. For the resolver, I’m not sure if there’s any processing that might be required there (like CNAME).

kerem commented

2026-03-15 23:24:04 +03:00

Author

Owner

@DevQps commented on GitHub (May 15, 2020):

For some reason the last comment that I wrote here did not end up here. Sorry for the late response. I initially meant the client code! So basically that we enable users to do a query for DNAME, or at least recognize DNAME attributes. Since it is basically the resolver that needs to act on the DNAME attributes I don't think it would add too much complexity to the server as well? Since it just needs to return the DNAME? Or am I wrong about this?

@DevQps commented on GitHub (May 15, 2020): For some reason the last comment that I wrote here did not end up here. Sorry for the late response. I initially meant the client code! So basically that we enable users to do a query for DNAME, or at least recognize DNAME attributes. Since it is basically the resolver that needs to act on the DNAME attributes I don't think it would add too much complexity to the server as well? Since it just needs to return the DNAME? Or am I wrong about this?

kerem commented

2026-03-15 23:24:10 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jun 27, 2020):

I didn't properly follow up on this.

indeed, DNAME in just the client should mostly be a matter of just adding the record types. That's usually pretty straight forward.

@bluejekyll commented on GitHub (Jun 27, 2020): I didn't properly follow up on this. indeed, DNAME in just the client should mostly be a matter of just adding the record types. That's usually pretty straight forward.

kerem referenced this issue

2026-03-16 02:12:27 +03:00

[PR #603] [MERGED] Enable clippy on stable #1550