[GH-ISSUE #63] Does geodns support cname chain? #49

New issue

Open

opened 2026-02-28 14:16:05 +03:00 by kerem · 5 comments

kerem commented

2026-02-28 14:16:05 +03:00

Owner

Originally created by @li45 on GitHub (Apr 29, 2015).
Original GitHub issue: https://github.com/abh/geodns/issues/63

Originally created by @li45 on GitHub (Apr 29, 2015). Original GitHub issue: https://github.com/abh/geodns/issues/63

kerem commented

2026-02-28 14:16:05 +03:00

Author

Owner

@abh commented on GitHub (Apr 29, 2015):

Can you give me an example of what you mean?

@abh commented on GitHub (Apr 29, 2015): Can you give me an example of what you mean?

kerem commented

2026-02-28 14:16:05 +03:00

Author

Owner

@li45 commented on GitHub (Apr 30, 2015):

my test.com.json:

    "bar" : {
        "a":[["192.168.1.2",100]]
    },
    "www":  {
        "cname": "bar.test.com."
    }

then run dig @127.0.0.1 www.test.com
response:

;; QUESTION SECTION:
;www.test.com.          IN  A

;; ANSWER SECTION:
www.test.com.   60  IN  CNAME   bar.test.com.

no A recode in here.

Expect response:

;; QUESTION SECTION:
;www.test.com.          IN  A

;; ANSWER SECTION:
www.test.com.   60  IN  CNAME   bar.test.com.
bar.test.com.    60 IN  A   192.168.1.2

@li45 commented on GitHub (Apr 30, 2015): my `test.com.json`: ``` "bar" : { "a":[["192.168.1.2",100]] }, "www": { "cname": "bar.test.com." } ``` then run `dig @127.0.0.1 www.test.com` response: ``` ;; QUESTION SECTION: ;www.test.com. IN A ;; ANSWER SECTION: www.test.com. 60 IN CNAME bar.test.com. ``` **no A recode in here.** Expect response: ``` ;; QUESTION SECTION: ;www.test.com. IN A ;; ANSWER SECTION: www.test.com. 60 IN CNAME bar.test.com. bar.test.com. 60 IN A 192.168.1.2 ```

kerem commented

2026-02-28 14:16:05 +03:00

Author

Owner

@abh commented on GitHub (Apr 30, 2015):

Ah, yes — I believe it works because the resolver will just query again for the other name, but obviously that could be optimized!

There’s an “alias” (I think it’s called) record type that “resolves” the CNAME internally.

I should fix the cname chain thing though.

@abh commented on GitHub (Apr 30, 2015): Ah, yes — I believe it works because the resolver will just query again for the other name, but obviously that could be optimized! There’s an “alias” (I think it’s called) record type that “resolves” the CNAME internally. I should fix the cname chain thing though.

kerem commented

2026-02-28 14:16:06 +03:00

Author

Owner

@semihalev commented on GitHub (Apr 30, 2015):

abh, for glue records, check my commit github.com/semihalev/geodns@fc9668252a, resolve internally for CNAME, MX, NS, but need small boolean (msg.CheckGlue) in dns lib.

@semihalev commented on GitHub (Apr 30, 2015): abh, for glue records, check my commit https://github.com/semihalev/geodns/commit/fc9668252a3c8012f59b2d7e63844053e9583cb3, resolve internally for CNAME, MX, NS, but need small boolean (msg.CheckGlue) in dns lib.

kerem commented

2026-02-28 14:16:06 +03:00

Author

Owner

@praveenkumar2608 commented on GitHub (Sep 12, 2020):

Ah, yes — I believe it works because the resolver will just query again for the other name, but obviously that could be optimized!

There’s an “alias” (I think it’s called) record type that “resolves” the CNAME internally.

I should fix the cname chain thing though.

@abh @semihalev Is this fixed. Facing same issue

@praveenkumar2608 commented on GitHub (Sep 12, 2020): > Ah, yes — I believe it works because the resolver will just query again for the other name, but obviously that could be optimized! > > There’s an “alias” (I think it’s called) record type that “resolves” the CNAME internally. > > I should fix the cname chain thing though. @abh @semihalev Is this fixed. Facing same issue