[GH-ISSUE #20] Support for all the other record types? MX, SPF, TXT, SRV, ...?

kerem commented

2026-02-28 14:15:53 +03:00

Owner

Originally created by @Doridian on GitHub (Nov 10, 2012).
Original GitHub issue: https://github.com/abh/geodns/issues/20

Is it already supported?
Becuase it does not reject them in the config, but never reply with them either.
Especially MX records would be really, really useful.

Originally created by @Doridian on GitHub (Nov 10, 2012). Original GitHub issue: https://github.com/abh/geodns/issues/20 Is it already supported? Becuase it does not reject them in the config, but never reply with them either. Especially MX records would be really, really useful.

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@abh commented on GitHub (Nov 11, 2012):

Hi Mark,

They are not. It's not a lot of code to add it, it's mostly a matter of deciding the configuration format.

For example for MX records we could do (inside a particular name) similar to how A/AAAA records work:

"mx": [ [ "mail.example.org", 20 ], [ "mail2.example.org", 10 ] ]

though are 10 and 20 "priorities" (as in regular MX records) or weights as in the A/AAAA records. The latter would be more useful if you are using geodns because you want to manage the "smarts" rather than letting the clients figure out what to do. The former (priorities) would be better if you are using geodns for the smarts for some records, but just need to serve some plain old ones here.

So anyway, I've been experimenting with that, but have come to the conclusion (I think, feedback would be welcome!) that the more future proof and sane variant would be to do:

"mx": [ { "data": "mail.example.org", "priority": 10, "weight": 500 }, { ... } ]

which would be more extensible, but feels a bit verbose. I think the valuable part of making it more verbose/explicit is that different record types more easily can fit into this without new users having to learn whatever crazy quirks we come up with for each type.

As a sidenote, it'd be a good idea to have it more consistently at least warn when it sees data it doesn't know what to do with.

@abh commented on GitHub (Nov 11, 2012): Hi Mark, They are not. It's not a lot of code to add it, it's mostly a matter of deciding the configuration format. For example for MX records we could do (inside a particular name) similar to how A/AAAA records work: ``` json "mx": [ [ "mail.example.org", 20 ], [ "mail2.example.org", 10 ] ] ``` though are 10 and 20 "priorities" (as in regular MX records) or weights as in the A/AAAA records. The latter would be more useful if you are using geodns because you want to manage the "smarts" rather than letting the clients figure out what to do. The former (priorities) would be better if you are using geodns for the smarts for some records, but just need to serve some plain old ones here. So anyway, I've been experimenting with that, but have come to the conclusion (I think, feedback would be welcome!) that the more future proof and sane variant would be to do: ``` json "mx": [ { "data": "mail.example.org", "priority": 10, "weight": 500 }, { ... } ] ``` which would be more extensible, but feels a bit verbose. I think the valuable part of making it more verbose/explicit is that different record types more easily can fit into this without new users having to learn whatever crazy quirks we come up with for each type. As a sidenote, it'd be a good idea to have it more consistently at least warn when it sees data it doesn't know what to do with.

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@Doridian commented on GitHub (Nov 11, 2012):

That format with the object style would infact be very nice and allow for stuff like SRV records to be speicifed better ("protocol", "port", "host" fields etc)

@Doridian commented on GitHub (Nov 11, 2012): That format with the object style would infact be very nice and allow for stuff like SRV records to be speicifed better ("protocol", "port", "host" fields etc)

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@abh commented on GitHub (Nov 15, 2012):

I'll add some documentation and maybe a few more record types in the next couple of days. For now you can see the format for MX records in dns/example.com.json.

@abh commented on GitHub (Nov 15, 2012): I'll add some documentation and maybe a few more record types in the next couple of days. For now you can see the format for MX records in `dns/example.com.json`.

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@scyclops commented on GitHub (Apr 26, 2013):

I'd love to see support for TXT records as well.

@scyclops commented on GitHub (Apr 26, 2013): I'd love to see support for TXT records as well.

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@abh commented on GitHub (Apr 28, 2013):

@scyclops 'txt' records are supported now. 😄

I guess I should do SPF and SRV too just so I can close the ticket here since those were the others mentioned.

@abh commented on GitHub (Apr 28, 2013): @scyclops 'txt' records are supported now. :smile: I guess I should do SPF and SRV too just so I can close the ticket here since those were the others mentioned.

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@cdown commented on GitHub (Oct 6, 2013):

Just echoing my desire for SPF records, this is a necessity for me before I can start using GeoDNS as part of our company infrastructure.

Thanks for the great work!

@cdown commented on GitHub (Oct 6, 2013): Just echoing my desire for SPF records, this is a necessity for me before I can start using GeoDNS as part of our company infrastructure. Thanks for the great work!

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@abh commented on GitHub (Oct 7, 2013):

@cdown do you really need SPF record type? I thought "SPF records" were still just TXT records in practice... No?

@abh commented on GitHub (Oct 7, 2013): @cdown do you really need SPF record type? I thought "SPF records" were still just TXT records in practice... No?

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@maxclark commented on GitHub (Oct 7, 2013):

SPF records are TXT records:

http://www.ietf.org/rfc/rfc4408.txt

On Mon, Oct 7, 2013 at 8:03 AM, Ask Bjørn Hansen
notifications@github.comwrote:

@cdown https://github.com/cdown do you really need SPF record type? I
thought "SPF records" were still just TXT records in practice... No?

—
Reply to this email directly or view it on GitHubhttps://github.com/abh/geodns/issues/20#issuecomment-25815876
.

@maxclark commented on GitHub (Oct 7, 2013): SPF records are TXT records: http://www.ietf.org/rfc/rfc4408.txt On Mon, Oct 7, 2013 at 8:03 AM, Ask Bjørn Hansen notifications@github.comwrote: > @cdown https://github.com/cdown do you really need SPF record type? I > thought "SPF records" were still just TXT records in practice... No? > > — > Reply to this email directly or view it on GitHubhttps://github.com/abh/geodns/issues/20#issuecomment-25815876 > .

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@cdown commented on GitHub (Oct 8, 2013):

@abh @maxclark They share the same format, but that doesn't make them identical (namely, the semantics of being an SPF record matter as well as the underlying format). From the same RFC:

3.1.1.  DNS Resource Record Types

   This document defines a new DNS RR of type SPF, code 99.  The format
   of this type is identical to the TXT RR [RFC1035].  For either type,
   the character content of the record is encoded as [US-ASCII].

   It is recognized that the current practice (using a TXT record) is
   not optimal, but it is necessary because there are a number of DNS
   server and resolver implementations in common use that cannot handle
   the new RR type.  The two-record-type scheme provides a forward path
   to the better solution of using an RR type reserved for this purpose.

   An SPF-compliant domain name SHOULD have SPF records of both RR
   types.  A compliant domain name MUST have a record of at least one
   type.  If a domain has records of both types, they MUST have
   identical content.  For example, instead of publishing just one
   record as in Section 3.1 above, it is better to publish:

      example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
      example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"

Since the presence of SPF records in addition to TXT records is marked as "SHOULD" by the RFC, I think this is worthy of implementation, especially since the goal is to continue to transition towards SPF records instead of TXT records for this purpose.

@cdown commented on GitHub (Oct 8, 2013): @abh @maxclark They share the same format, but that doesn't make them identical (namely, the semantics of being an SPF record matter as well as the underlying format). From the same RFC: ``` 3.1.1. DNS Resource Record Types This document defines a new DNS RR of type SPF, code 99. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as [US-ASCII]. It is recognized that the current practice (using a TXT record) is not optimal, but it is necessary because there are a number of DNS server and resolver implementations in common use that cannot handle the new RR type. The two-record-type scheme provides a forward path to the better solution of using an RR type reserved for this purpose. An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. If a domain has records of both types, they MUST have identical content. For example, instead of publishing just one record as in Section 3.1 above, it is better to publish: example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" ``` Since the presence of SPF records in addition to TXT records is marked as "SHOULD" by the RFC, I think this is worthy of implementation, especially since the goal is to continue to transition towards SPF records instead of TXT records for this purpose.

kerem commented

2026-02-28 14:15:54 +03:00

Author

Owner

@maxclark commented on GitHub (Oct 8, 2013):

Chris,

Have you tried configuring a TXT record yet? It might just do what you want.

-Max

~ mclark$ host -t spf google.com
google.com has no SPF record
~ mclark$ host -t txt google.com
google.com descriptive text "v=spf1 include:_spf.google.com ip4:
216.73.93.70/31 ip4:216.73.93.72/31 ~all"

On Mon, Oct 7, 2013 at 9:26 PM, Chris Down notifications@github.com wrote:

Anything in the following post is "please correct me if I'm wrong"
territory. :-)

@abh https://github.com/abh As far as I know, SPF is a separate RR type
from TXT, whilst sharing the same attributes.

@maxclark https://github.com/maxclark They share the same attributes,
but as far as I am aware, they're not interchangeable RR types. From that
RFC:

3.1.1. DNS Resource Record Types

This document defines a new DNS RR of type SPF, code 99. The format
of this type is identical to the TXT RR [RFC1035]. For either type,
the character content of the record is encoded as [US-ASCII].

It is recognized that the current practice (using a TXT record) is
not optimal, but it is necessary because there are a number of DNS
server and resolver implementations in common use that cannot handle
the new RR type. The two-record-type scheme provides a forward path
to the better solution of using an RR type reserved for this purpose.

An SPF-compliant domain name SHOULD have SPF records of both RR
types. A compliant domain name MUST have a record of at least one
type. If a domain has records of both types, they MUST have
identical content. For example, instead of publishing just one
record as in Section 3.1 above, it is better to publish:
  example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
  example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
I require the SPF records before I can use this because we have a
particularly virulent piece of "enterprise" software that refuses to
operate unless I have SPF records.

—
Reply to this email directly or view it on GitHubhttps://github.com/abh/geodns/issues/20#issuecomment-25864176
.

@maxclark commented on GitHub (Oct 8, 2013): Chris, Have you tried configuring a TXT record yet? It might just do what you want. -Max ~ mclark$ host -t spf google.com google.com has no SPF record ~ mclark$ host -t txt google.com google.com descriptive text "v=spf1 include:_spf.google.com ip4: 216.73.93.70/31 ip4:216.73.93.72/31 ~all" On Mon, Oct 7, 2013 at 9:26 PM, Chris Down notifications@github.com wrote: > Anything in the following post is "please correct me if I'm wrong" > territory. :-) > > @abh https://github.com/abh As far as I know, SPF is a separate RR type > from TXT, whilst sharing the same attributes. > > @maxclark https://github.com/maxclark They share the same attributes, > but as far as I am aware, they're not interchangeable RR types. From that > RFC: > > 3.1.1. DNS Resource Record Types > > This document defines a new DNS RR of type SPF, code 99. The format > of this type is identical to the TXT RR [RFC1035]. For either type, > the character content of the record is encoded as [US-ASCII]. > > It is recognized that the current practice (using a TXT record) is > not optimal, but it is necessary because there are a number of DNS > server and resolver implementations in common use that cannot handle > the new RR type. The two-record-type scheme provides a forward path > to the better solution of using an RR type reserved for this purpose. > > An SPF-compliant domain name SHOULD have SPF records of both RR > types. A compliant domain name MUST have a record of at least one > type. If a domain has records of both types, they MUST have > identical content. For example, instead of publishing just one > record as in Section 3.1 above, it is better to publish: > > ``` > example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" > example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" > ``` > > I require the SPF records before I can use this because we have a > particularly virulent piece of "enterprise" software that refuses to > operate unless I have SPF records. > > — > Reply to this email directly or view it on GitHubhttps://github.com/abh/geodns/issues/20#issuecomment-25864176 > .

kerem commented

2026-02-28 14:15:55 +03:00

Author

Owner

@cdown commented on GitHub (Oct 8, 2013):

It doesn't, sadly.

My use case is irrelevant though -- my main argument is that the RFC very clearly wants people to use SPF records, not TXT records.

@cdown commented on GitHub (Oct 8, 2013): It doesn't, sadly. My use case is irrelevant though -- my main argument is that the RFC very clearly wants people to use SPF records, not TXT records.

kerem commented

2026-02-28 14:15:55 +03:00

Author

Owner

@maxclark commented on GitHub (Oct 8, 2013):

The RFC wants you to use both if the DNS server implements the SPF record type. IIRC bind is the only DNS server that implements SPF at this time while everything else uses txt.

—
Sent from Mailbox for iPad

On Tue, Oct 8, 2013 at 2:04 AM, Chris Down notifications@github.com
wrote:

It doesn't, sadly.

My use case is irrelevant though -- my main argument is that the RFC very clearly wants people to use SPF records, not TXT records.

Reply to this email directly or view it on GitHub:
https://github.com/abh/geodns/issues/20#issuecomment-25874465

@maxclark commented on GitHub (Oct 8, 2013): The RFC wants you to use both if the DNS server implements the SPF record type. IIRC bind is the only DNS server that implements SPF at this time while everything else uses txt. — Sent from Mailbox for iPad On Tue, Oct 8, 2013 at 2:04 AM, Chris Down notifications@github.com wrote: > It doesn't, sadly. > > ## My use case is irrelevant though -- my main argument is that the RFC very clearly wants people to use SPF records, not TXT records. > > Reply to this email directly or view it on GitHub: > https://github.com/abh/geodns/issues/20#issuecomment-25874465

kerem commented

2026-02-28 14:15:55 +03:00

Author

Owner

@cdown commented on GitHub (Oct 9, 2013):

I know that djbdns and nsd (two other extremely popular servers) implement it, it's definitely not just bind.

Even if they didn't, I don't see how that's a good argument to ignore the IETF's clearly desired transition to SPF...

@cdown commented on GitHub (Oct 9, 2013): I know that djbdns and nsd (two other extremely popular servers) implement it, it's definitely not just bind. Even if they didn't, I don't see how that's a good argument to ignore the IETF's clearly desired transition to SPF...

kerem commented

2026-02-28 14:15:55 +03:00

Author

Owner

@abh commented on GitHub (Oct 9, 2013):

Do you know of any non-hobby/small-business domains that use SPF (type 99) records? I tried google.com, yahoo.com, gmail.com and a bunch others and didn't find any.

The current draft for the next version of the SPF RFC says to just use TXT records, I think because that's what everybody does: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-3.1

That being said, patches welcome – I'm just not going to do it before I've done other work that's more useful (to me). :-)

@abh commented on GitHub (Oct 9, 2013): Do you know of any non-hobby/small-business domains that use SPF (type 99) records? I tried google.com, yahoo.com, gmail.com and a bunch others and didn't find any. The current draft for the next version of the SPF RFC says to just use TXT records, I think because that's what everybody does: http://tools.ietf.org/html/draft-ietf-spfbis-4408bis-21#section-3.1 That being said, patches welcome – I'm just not going to do it before I've done other work that's more useful (to me). :-)

kerem commented

2026-02-28 14:15:55 +03:00

Author

Owner

@cdown commented on GitHub (Oct 9, 2013):

github.com uses them, off the top of my head.

I will send a patch if I can understand the code well enough and have the time, I guess. Unfortunately this makes geodns unusable for me right now.

Thanks anyway. :-)

@cdown commented on GitHub (Oct 9, 2013): github.com uses them, off the top of my head. I will send a patch if I can understand the code well enough and have the time, I guess. Unfortunately this makes geodns unusable for me right now. Thanks anyway. :-)

kerem commented

2026-02-28 14:15:55 +03:00

Author

Owner

@abh commented on GitHub (Oct 9, 2013):

You might just need to add a few lines to zones.go to have it know how to add SPF records into the zone.

@abh commented on GitHub (Oct 9, 2013): You might just need to add a few lines to zones.go to have it know how to add SPF records into the zone.

kerem commented

2026-02-28 14:15:55 +03:00

Author

Owner

@afsheenb commented on GitHub (Jan 7, 2014):

I've taken an initial stab at adding support for SPF records (basically making a new TXT record that is not a TXT record, which meets the RFC requirements if I'm reading them right. abh and cdown, let me know if this is welcome / if I'm on the right track, I just wanted to dip my toe in and see how difficult this would be.

@afsheenb commented on GitHub (Jan 7, 2014): I've taken an initial stab at adding support for SPF records (basically making a new TXT record that is not a TXT record, which meets the RFC requirements if I'm reading them right. abh and cdown, let me know if this is welcome / if I'm on the right track, I just wanted to dip my toe in and see how difficult this would be.

kerem commented

2026-02-28 14:15:55 +03:00

Author

Owner

@cdown commented on GitHub (Jan 7, 2014):

In the meantime my broken software actually allowed using TXT records :-D

Having SPF records in here while non-draft RFCs promote them is a good idea, though, in my opinion.

@cdown commented on GitHub (Jan 7, 2014): In the meantime my broken software actually allowed using TXT records :-D Having SPF records in here while non-draft RFCs promote them is a good idea, though, in my opinion.

kerem commented

2026-02-28 14:15:55 +03:00

Author

Owner

@afsheenb commented on GitHub (Jun 18, 2014):

All of the records mentioned in the inital issue (MX, SPF, TXT and SRV) are now supported by geodns. I believe it's safe to close this.

@afsheenb commented on GitHub (Jun 18, 2014): All of the records mentioned in the inital issue (MX, SPF, TXT and SRV) are now supported by geodns. I believe it's safe to close this.

kerem referenced this issue

2026-03-01 17:24:16 +03:00

[GH-ISSUE #18] Incorrect 'getting started' command in README #160

kerem referenced this issue

2026-03-13 14:35:16 +03:00

[GH-ISSUE #18] Incorrect 'getting started' command in README #302

Rows
Columns

[GH-ISSUE #20] Support for all the other record types? MX, SPF, TXT, SRV, ...? #18

My use case is irrelevant though -- my main argument is that the RFC very clearly wants people to use SPF records, not TXT records.