Ancestors

Toot

Written by Solarbird :flag_cascadia: on 2025-01-29 at 01:47

ETA: Okay the below is fixed, but why would db.root not update when everything else does?

(it's on Debian)

okay this is weird

the root hints file I have diffs identically to the one I just pulled down from the internic as a sanity check (other than the last updated date which is also weird)

but I'm getting this regardless:

named[1252171]: checkhints: b.root-servers.net/A (170.247.170.2) missing from hints

named[1252171]: checkhints: b.root-servers.net/A (199.9.14.201) extra record in hints

(and similar for the IP6, elided for space)

why

[#]bind #named #sysadmin #ItsAlwaysDNS #why

=> More informations about this toot | More toots from moira@mastodon.murkworks.net

Descendants

Written by wohali on 2025-01-29 at 01:50

@moira https://bugs.launchpad.net/ubuntu-docker-images/+bug/2045807

looks like it may be referencing a different file somewhere?

=> More informations about this toot | More toots from wohali@octodon.social

Written by Solarbird :flag_cascadia: on 2025-01-29 at 02:01

@wohali this is a preeeeeeeeetty old server, I'll admit that...

[pokes around]

huh

[pokes around more]

well that's neat

I guess db.root didn't update when everything else did, that's "fun"

thanks!

[manually updates it]

=> More informations about this toot | More toots from moira@mastodon.murkworks.net

Written by DrScriptt on 2025-01-29 at 02:45

@moira as a bind admin of 25 years, I’ll say the answer is in your question.

named[1252171]: checkhints: b.root-servers.net/A (170.247.170.2) missing from hints

named[1252171]: checkhints: b.root-servers.net/A (199.9.14.201) extra record in hints

As someone who had to learn how to unpack that message, I’ll say this.

I bet if you look in the file that named is looking at, the A (IP) record for b.root-servers.net is 199.9.14.201.

Named is saying that record is there and shouldn’t be / doesn’t belong there.

Named is also saying that the record with 170.247.170.2 isn’t there when it should be.

This is caused by the b.root-servers.net re-addressing from 199.9.14.201 to 170.247.170.2. And the contents of the file are from before the re-address.

=> More informations about this toot | More toots from drscriptt@oldbytes.space

Written by DrScriptt on 2025-01-29 at 02:48

@moira the file used to be called root.hints because it was only to help named (give it a hint) at one point in time.

There is a version of the same information compiled into named.

Named uses the information; compiled in and / or hi t file, to find one root name server that it can use to query all the other names to dynamically build a current (for that daemon invocation) list of root servers.

=> More informations about this toot | More toots from drscriptt@oldbytes.space

Written by Solarbird :flag_cascadia: on 2025-01-29 at 02:50

@drscriptt Yes, I know, I guess your instance didn't catch the edits.

/usr/share/dns/root.hints got updated as intended, but db.root didn't for some reason, and I updated the question to wonder why that didn't also update.

=> More informations about this toot | More toots from moira@mastodon.murkworks.net

Written by Patrick Mevzek on 2025-01-29 at 02:48

@moira B root servers changed IP address "recently", 2023-05-16, see https://b.root-servers.org/news/2023/05/16/new-addresses.html ; so lots of content won't have the new IP, which is what bind tells you. How? He does priming on boot. It uses that file to contact nameservers listed and ask them for their IP addresses and hence discover the discrepancy. Just update the file, restart, and you are set "for now".

=> More informations about this toot | More toots from pmevzek@framapiaf.org

Written by Solarbird :flag_cascadia: on 2025-01-29 at 02:51

@pmevzek I don't think my edit distributed. :/

Yeah, I found out that db.root didn't update even though /usr/share/dns/root.hints did, so the question for me now is why? I would've thought that since db.root is part of the package that it would've updated too - but it didn't.

=> More informations about this toot | More toots from moira@mastodon.murkworks.net

Written by Patrick Mevzek on 2025-01-29 at 03:00

@moira It depends also on your bind version, you don't say. Because bind is shipped in its source code with the equivalent file, no matter what is on disk. It was changed in source code for version 9.19.18 so you need to upgrade at least to that. OR any other version where source code was patched. See https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8371/diffs?commit_id=2ca2f7e9852a3d6e93f065c01ea4679f723688f7

=> More informations about this toot | More toots from pmevzek@framapiaf.org

Written by Solarbird :flag_cascadia: on 2025-01-29 at 03:08

@pmevzek Debian 12 (Bookworm), latest package, which is... 1:9.18.28-1~deb12u2. So with 9.19.18 db.root will also update with root.hints, then?

(I manually updated it already, the original problem is solved. But db.root should've updated too _in my opinion.)

=> More informations about this toot | More toots from moira@mastodon.murkworks.net

Written by Patrick Mevzek on 2025-01-29 at 07:03

@moira Like I said the software source code includes that data. It is INSIDE the program. Once compiled it won't update itself, no matter what. You need to install a newer version compiled with newer source code that was updated with the new IPs.

=> More informations about this toot | More toots from pmevzek@framapiaf.org

Written by Solarbird :flag_cascadia: on 2025-01-29 at 09:02

@pmevzek ...no, it's loaded at startup time, and editing the db.root copy of the file got rid of the warnings.

=> More informations about this toot | More toots from moira@mastodon.murkworks.net

Written by Patrick Mevzek on 2025-01-29 at 14:37

@moira Which is what was said at the beginning, edit the files !

=> More informations about this toot | More toots from pmevzek@framapiaf.org

Written by Trouble on 2025-01-29 at 06:31

@moira ye haw! Someone who still runs bind! One of the few, but proud!

=> More informations about this toot | More toots from trouble@masto.ai

Written by Solarbird :flag_cascadia: on 2025-01-29 at 09:01

@trouble ...what? bind9 in particular. I thought bind9 was incredibly common. no?

=> More informations about this toot | More toots from moira@mastodon.murkworks.net

Written by Trouble on 2025-01-31 at 16:55

@moira most people use the caving DNS on their router. A few run it in caching mode, where you still point to 8.8.8.8 or your ISP. Even fewer run it as an authoritative, point to root servers config. I used to, but using my router, caching results from 8.8.8.8, is just easier.

=> More informations about this toot | More toots from trouble@masto.ai

Written by Solarbird :flag_cascadia: on 2025-01-31 at 17:22

@trouble oh you mean people who don’t host servers, okay.

I was going to say we likely wouldn’t either except then I remembered how much Comcast’s onboard router software sucks so maybe we still would!

(When we were still on Comcast Business as our upstream - they were a monopoly provider for a while - we dramatically improved everything, particularly latency, by adding two more machines between our LAN and it, shutting off every piece of functionality we could and moving it to our NS. Even plugging a second cable into its onboard hub made performance drop measurably. So bad.)

=> More informations about this toot | More toots from moira@mastodon.murkworks.net

Written by Solarbird :flag_cascadia: on 2025-01-31 at 17:25

@trouble yes, plugging in our own hub into its hub and moving the server cables from its onboard hub to ours was measurably better despite adding a whole new layer of hardware. it was appalling.

=> More informations about this toot | More toots from moira@mastodon.murkworks.net

Written by Trouble on 2025-01-31 at 22:21

@moira oh, I've never trusted the security of the ISP firewall and have always provided my own. But yes, I have run bind at home where I was running raw Linux iptables rules as a firewall. Fun times!

=> More informations about this toot | More toots from trouble@masto.ai