net: LookupTXT regards a TXT record with multiple strings as multiple records on Windows #21472
Comments
|
Can you please include the output reported by dig.
… On 16 Aug 2017, at 21:51, cedar10bits ***@***.***> wrote:
What version of Go are you using (go version)?
go1.7.6 windows/amd64
What did you do?
"example.test.local" is a domain which has a TXT record with multiple strings like below.
"v=spf1 ip4:1.2.3.4 " "~all"
I resolve TXT record of "example.test.local".
txts, err := net.LookupTXT("example.test.local")
What did you expect to see?
On Linux, behave like below(go1.7.6 linux/amd64).
len(txts) == 1
txts[0] == "v=spf1 ip4:1.2.3.4 ~all"
What did you see instead?
On Windows, behave like below.
len(txts) == 2
txts[0] == "v=spf1 ip4:1.2.3.4"
txts[1] == "~all"
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
The relevant rfc for this discussion is, https://tools.ietf.org/html/rfc1464
… On 16 Aug 2017, at 21:58, Dave Cheney ***@***.***> wrote:
Can you please include the output reported by dig.
> On 16 Aug 2017, at 21:51, cedar10bits ***@***.***> wrote:
>
> What version of Go are you using (go version)?
>
> go1.7.6 windows/amd64
>
> What did you do?
>
> "example.test.local" is a domain which has a TXT record with multiple strings like below.
> "v=spf1 ip4:1.2.3.4 " "~all"
>
> I resolve TXT record of "example.test.local".
> txts, err := net.LookupTXT("example.test.local")
>
> What did you expect to see?
>
> On Linux, behave like below(go1.7.6 linux/amd64).
>
> len(txts) == 1
> txts[0] == "v=spf1 ip4:1.2.3.4 ~all"
> What did you see instead?
>
> On Windows, behave like below.
>
> len(txts) == 2
> txts[0] == "v=spf1 ip4:1.2.3.4"
> txts[1] == "~all"
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
|
|
ianlancetaylor
changed the title
|
Looks like on Windows |
|
This patch works well. |
|
@cedar10bits Thanks. To avoid any licensing confusion, we will only look at patches that go through the regular contribution process described at https://golang.org/doc/contribute. Would you be willing to send your patch through that? |
|
I've been researching this this morning and I'm not sure this txt record is well formed. Paging @miekg to issue triage. Stat. |
|
Relevant RFC is 1035, 1464 is EXPERIMENTAL. what windows does is completely legal. Sorry it took 8 hours, I was asleep |
|
@miekg Thanks.
The above describes only <character-string> format.
And if what Windows does is completely legal, what Linux does will be illegal. |
|
I'm sorry, I'm lost here. This bug is about behavior on windows. |
|
I think this bug is about different behavior between on Windows and on Linux. |
|
For your reference, nslookup on Windows returns these results below. [multiple TXT records]
[single TXT record with multiple strings]
|
|
I am happy to change code, but I would like to see the problem for myself first. @cedar10bits do you have an example DNS server that I can use to reproduce this problem? Or alternatively maybe someone can suggest a way to easily setup / configure this server on Windows or Linux. Thank you. Alex |
@alexbrainman I don't have my own DNS server which can access globally.
|
I will try when I have some time. Thank you @cedar10bits Alex |
|
Ah yes, if the zone file has this: Then what happens on Windows is correct, what happen under Linux is not correct. I.e. you should receive 2 txts elements. Do you want them to be concatenated when returned from the API? Probably not, because the splitting might be done on purpose (by the zone administrator). |
|
I run this program: on Linux: and on Windows: @miekg which version needs to be fixed? I suspect Windows is wrong here. Thank you. Alex |
@miekg I think so, too. I think this API should be defined as below, ideally. But this API is defined as a function that returns multiple TXT records of a string array (https://golang.org/pkg/net/#LookupTXT). |
@miekg If removed, just concatenate them without adding spaces. |
|
But LookupTXT has no idea it deals with SPF records (oh if only they had used a new record type...), so following those rules in 7208 doesn't work for all cases. @alexbrainman using Building this with Checking with dig: So indeed on Linux this look OK (Don't own Windows - so can't check there). What's wrong with Windows? The order of the different txt segments? (At least that is what I can make out). It could be that on the windows tests the TXT order is different (unlikely). What does |
I know those rules are only for SPF (multiple strings), not for TXT records. That's OK. Here is what nslookup gives on Windows (instead of dig). @alexbrainman using What this gives on Linux (CGO_ENABLED=0) is below: And what this gives on Windows is below: On Windows, "v=spf1 ... " and " include: ... " are regarded as two other TXT records (not single TXT record). |
|
ah thanks @cedar10bits now I see (these strings are too long). Again Windows code seems correct to me, what happens on Linux is somewhat fishy. |
|
This API is defined as below (https://golang.org/pkg/net/#LookupTXT). This API returns TXT records as a string array. |
|
Well that's DNS for you. What Windows does here makes sense from a DNS
perspective.
On Aug 23, 2017 12:25 PM, "cedar10bits" <notifications@github.com> wrote:
This API is defined as below (https://golang.org/pkg/net/#LookupTXT).
LookupTXT returns the DNS TXT records for the given domain name.
This API returns TXT records as a string array.
I think that one element of this string array must be single TXT record,
not a part of a TXT record.
v=spf1 is a part of a TXT record, but not single TXT record.
If Windows code is correct, behavior on Windows is not followed by this
API's definition.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21472 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAVkW2gyqidboyazexrKPmf9k87taMypks5sbAw0gaJpZM4O4zEm>
.
|
|
If what Windows does is correct, I will have no idea to distinguish between single whole TXT record and a part of TXT record. |
|
I think the answer should be, if you care about that maybe you shouldn't
use txt records to store stuff your interested in.
Otoh is seems the API should have returned a slice of slices. Obviously we
can't change that anymore. Concatenating txt segments like this might be ok
for spf, but may not work for other txt uses. spf is a broken standard seen
from the DNS standpoint.
…On Aug 23, 2017 12:54 PM, "cedar10bits" ***@***.***> wrote:
If what Windows does is correct, I will have no idea to distinguish
between single whole TXT record and a part of TXT record.
To use this API correctly, I need to distinguish.
@miekg <https://github.com/miekg> do you have any idea ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21472 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAVkW71JCnP9Kjr7YHyzicy9B6RthZWDks5sbBL5gaJpZM4O4zEm>
.
|
|
To understand DNS standpoint, I study DNS zone file. Zone file of bbc.com may be written like below (TXT record only): On Windows, this API regards zone file as below: And on Linux, this API regards as below (syntax error occurs on BIND because of too long strings): Is the above correct ? |
|
I've given my answers in previous comments |
|
I do not have any suggestions. But I decided to implement LookupTXT that returns [][]string instead of []string on windows. Then this program outputs So that would have been perfect. No? Alex |
|
@miekg I don't think behavior on Windows is legal on DNS standpoint. @alexbrainman Thank you. Maybe I can use it. |
If net.LookupTXT is important enough from security point of view or something, maybe we could mark net.LookupTXT as depreciated and add new net.ZZZLookupTXT function. I do not know enough about this to decide. Alex |
|
[ Quoting <notifications@github.com> in "Re: [golang/go] net: LookupTXT rega..." ]
> I wish net.LookupTXT were like this.
If net.LookupTXT is important enough from security point of view or something, maybe we could mark net.LookupTXT as depreciated and add new net.ZZZLookupTXT function. I do not know enough about this to decide.
I would consider LookupTXT good enough at this point. If you need more, you'll
need to use a specialized DNS package (which requires more code, but gives you
far more control - as so far DNS lets you).
It *may* be worth adding another TXT lookup function, but not sure what that
adds, not everything needs to be in the std lib.
|
Sounds good to me. Alex |
Sorry, I do not close this. Package net is portable standard library (see overview). net.LookupTXT is not portable because of different behavior between on Windows and on Linux. |
|
Closing as unfortunate. |
|
Why close ? To support legacy code portability, net.LookupTXT should be fixed. |
What do you propose we do? Alex |
If we leave this API what it is, this API is not portable.
I would like to propose first one (and fix Windows version). |
|
[ Quoting <notifications@github.com> in "Re: [golang/go] net: LookupTXT rega..." ]
> What do you propose we do?
If we leave this API what it is, this API is not portable.
Some codes already use this API and these must be portable.
To avoid this, we have two options.
1. Fix this API to equalize both behavior on Windows and on Linux.
2. Add new API instead of this API in the future (deprecate this API).
I would like to propose first one (this API should not separate single TXT record).
But now, option 2 seems to be adopted.
If adopt 2, we need to decide when to add.
Other than the difference between Windows and Linux, what *is* the actually
problem here?
|
Almost nothing. If fix the behavior, we cannot decide how to fix. |
Since I know nothing about DNS, I won't be able to implement this. So if you want this implemented you have to do it yourself. And I am not sure your change will be accepted - your change might be considered as "changing behavior too much". But you have to try to find out.
I called this option, but I don't see this accepted, unless we can demonstrate that current behavior is very bad (security wise or something). I don't think "the difference between Windows and Linux" is good enough reason to introduce new API. Alex |
|
@alexbrainman
I will implement this if accepted.
Having thought about this, I think so, too.
FYI, |
We cannot change existing API because existing programs that use net.LookupTXT will fail to build, so this change is not allowed as per https://golang.org/doc/go1compat Alex |
It was said in an inappropriate way. |
I am not the person who decides here. If you are OK with your changes to be rejected, feel free to try and send your changes for review. Alex |
|
[ Quoting <notifications@github.com> in "Re: [golang/go] net: LookupTXT rega..." ]
> I want to change behavior of LookupTXT(name string)
> And I want to add extra API, LookupTXTWithSep(name, sep string)
I am not the person who decides here. If you are OK with your changes to be rejected, feel free to try and send your changes for review.
1. was discussed at length in this thread, so I'm not sure why it is being
brought back.
2. Is not a good idea. I'm also entirely unsure why this needs to be in the std
lib.
/Miek
…--
Miek Gieben
|
A function in std lib must be consistent behavior even if called on any OS. |
|
This is really very simple. I'm sorry we wasted 50 comments on it. The actual DNS response is a sequence of RRs each containing a sequence of string fragments. The correct handling of the response is to do: (look at dnsRR_TXT.Walk, used on most platforms). The Windows code incorrectly does: (look at Resolver.lookupTXT in lookup_windows.go). Fix at https://golang.org/cl/79555 |
|
Change https://golang.org/cl/79555 mentions this issue: |
What version of Go are you using (
go version)?go1.7.6 windows/amd64
What did you do?
"example.test.local" is a domain which has a TXT record with multiple strings as below.
I resolve TXT record of "example.test.local".
What did you expect to see?
On Linux, behave like below(go1.7.6 linux/amd64).
len(txts) == 1txts[0] == "v=spf1 ip4:1.2.3.4 ~all"What did you see instead?
On Windows, behave like below.
len(txts) == 2txts[0] == "v=spf1 ip4:1.2.3.4 "txts[1] == "~all"The text was updated successfully, but these errors were encountered: