Trust-ad directive causes index is out of range

[vectomon]

I'm trying to use lego, which uses this library.
When this library tries to parse our system's /etc/resolv.conf, which contains the following content:

nameserver 127.0.0.11
options edns0 trust-ad ndots:0

I get this error:

goroutine 1 [running]:
github.com/miekg/dns.ClientConfigFromReader(0x10e1d80, 0xc000010038, 0x0, 0x0, 0xc000010038)
github.com/miekg/dns/clientconfig.go:94 +0x8d1
github.com/miekg/dns.ClientConfigFromFile(0xeeb9f6, 0x10, 0x0, 0x0, 0x0)
github.com/miekg/dns/clientconfig.go:29 +0xde
github.com/go-acme/lego/challenge/dns01.getNameservers(0xeeb9f6, 0x10, 0x16fd460, 0x2, 0x2, 0x0, 0x0, 0x27)
github.com/go-acme/lego/challenge/dns01/nameserver.go:74 +0x39
github.com/go-acme/lego/challenge/dns01.init()
github.com/go-acme/lego/challenge/dns01/nameserver.go:29 +0x7b

The problem is that it is indexing out of array, but I don't have the exact text of it. :(

I couldn't try it with the newest version of library, but the functionality of the code should be the same as the v1.1.15 which I have.

It has problems with the trust-ad directive, which is a standard directive, if I remove it, then it works fine.

Could you take a look at it?

Thanks! :)

[miekg]

[ Quoting <notifications@github.com> in "[miekg/dns] Trust-ad directive caus..." ]

nameserver 127.0.0.11 options edns0 trust-ad ndots:0 I get this error:

I can't replicate. Do you have an example where this library crashes?

It has problems with the trust-ad directive, which is a standard directive, if I remove it, then it works fine.

Those options healivy depend on your libc. My system doesn't have it. /Miek

…

-- Miek Gieben

[vectomon]

Well lego is an acme client, it would be a bit complicated to share an example with you.
Sadly, I don't know go, so I'm not able to try call miekg/dns.ClientConfigFromFile myself to try out.
All I can say that we use Ubuntu Server 20.04 LTS, running a Docker and a container inherits this file with some additional contents.

But I can tell you what happens:
Lego passes /etc/resolv.conf to miekg/dns.ClientConfigFromFile (see) and our file contains the text you can see in the OP.

When I remove the trust-ad from the file, it works just fine.

If you still need a proper example, then I will figure something out.

[miekg]

Doesn't look like something we can fix here /close

…

On Fri, 26 Feb 2021, 22:03 vectomon, ***@***.***> wrote: Well lego <https://github.com/go-acme/lego> is an acme client, it would be a bit complicated to share an example with you. Sadly, I don't know go, so I'm not able to try call miekg/dns.ClientConfigFromFile myself to try out. But I can tell you what happens: Lego passes /etc/resolv.conf to miekg/dns.ClientConfigFromFile (see <https://github.com/go-acme/lego/blob/7cfcc155ee3c88c9689d5ef5fc76692e2a4867b0/challenge/dns01/nameserver.go#L30>) and our file contains the text you can see in the OP. When I remove the trust-ad <https://man7.org/linux/man-pages/man5/resolv.conf.5.html> from the file, it works just fine. If you still need a proper example, then I will figure something out. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACWIW2F525EZS6535LLJLTTBAEDBANCNFSM4YISBBEQ> .

[tmthrgd]

I just dug into this a little, but you must have a really old version of miekg/dns somehow. There was a panic in ClientConfigFromReader that would be triggered by options that are exactly 8-bytes long (see #642), lo and behold "trust-ad" is 8-bytes long. That was fixed back in March of 2018 as part of miekg/dns@v1.0.5. The line number also matches that bug.

It was definitely fixed in miekg/dns@v1.1.15 though which is the earliest ever listed in lego's go.mod file. I have no idea how you'd have ended up with an older version than that, but that's the only way it could panic there.

You're definitely not using v1.1.15 though because line 94 is, well, this:

dns/clientconfig.go

Line 94 in b136750

}

Anyhow, you've somehow come to depend on a very old version and there's nothing we can do here because it's already been fixed. Bumping your dependency with go get will likely fix it.