search

abh / geodns

DNS server with per-client targeted responses
Apache License 2.0
1.39k stars 194 forks source link

Support for all the other record types? MX, SPF, TXT, SRV, ...? #20

Open Doridian opened 12 years ago

Doridian commented 12 years ago

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.

abh commented 12 years ago

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.

Doridian commented 12 years ago

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)

abh commented 12 years ago

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.

scyclops commented 11 years ago

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

abh commented 11 years ago

@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.

cdown commented 11 years ago

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!

abh commented 11 years ago

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

maxclark commented 11 years ago

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 .

cdown commented 11 years ago

@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.

maxclark commented 11 years ago

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 .

cdown commented 11 years ago

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.

maxclark commented 11 years ago

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

cdown commented 11 years ago

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...

abh commented 11 years ago

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). :-)

cdown commented 11 years ago

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. :-)

abh commented 11 years ago

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

afsheenb commented 10 years ago

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.

cdown commented 10 years ago

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.

afsheenb commented 10 years ago

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.