Some root-servers.net capitalised

doktornotor

Enable Forwarding Mode: Controls whether Unbound will query root servers directly (unchecked, disabled) or if queries will be forwarded to the upstream DNS servers defined under System > General

…

DNS Servers - None specified in the 4 DNS server fields & GW drop down.
DNS Query Forwarding is ticked (opposite to 1st fw).

Perhaps you could think a bit about what you are doing…

firewalluser

@doktornotor:

@firewalluser:

Enable Forwarding Mode: Controls whether Unbound will query root servers directly (unchecked, disabled) or if queries will be forwarded to the upstream DNS servers defined under System > General

…

DNS Servers - None specified in the 4 DNS server fields & GW drop down.
DNS Query Forwarding is ticked (opposite to 1st fw).

Perhaps you could think a bit about what you are doing…

https://doc.pfsense.org/index.php/Unbound_DNS_Resolver
" Enable Forwarding Mode: Controls whether Unbound will query root servers directly (unchecked, disabled) or if queries will be forwarded to the upstream DNS servers defined under System > General or those obtained by DHCP/PPPoE/etc (checked, enabled).

Forwarding mode may be enabled if the upstream DNS servers are trusted and also provide DNSSEC support. Forwarding mode is necessary for Multi-WAN Configurations. "

Both have DNSSEC enabled, so is the bold text wrong?

Likewise
"Unbound will query root servers directly (unchecked, disabled)"
" if queries will be forwarded to the upstream DNS servers defined under System > General "

"In the VM (2nd) fw connected to the internet connected (1st) fw
System:General Setup
DNS Servers - None specified in the 4 DNS server fields & GW drop down.
Allow DNS to be overridden by DHCP/PPP on Wan is ticked (opposite to 1st fw).
Do not use the DNS Forwarder as DNS Server is ticked (opposite to 1st fw).
Dashboard shows DNS Server = 1st fw static ip address only.
"

those obtained by DHCP/PPPoE/etc (checked, enabled)
"In the VM (2nd) fw connected to the internet connected (1st) fw
System:General Setup
DNS Servers - None specified in the 4 DNS server fields & GW drop down.
Allow DNS to be overridden by DHCP/PPP on Wan is ticked (opposite to 1st fw).
Do not use the DNS Forwarder as DNS Server is ticked (opposite to 1st fw).
Dashboard shows DNS Server = 1st fw static ip address only.
"

or is interpreted as not AND ie not AND or OR, OR is exclusive, although the dashboard shows its getting the 1st fw static ip address only, ie no 127.0.0.1 is showing.

It seems weird imo, which is why I have been rebooting these. I dont think I need to do a powerdown as per the problems users have experienced with upgrades from earlier versions https://forum.pfsense.org/index.php?topic=93071.0 because these are fresh installations from iso's.

doktornotor

TL;DR

Dude when you don't specify any upstream DNS servers there's nothing to forward to. PERIOD. Severe case of PEBKAC.

EDIT: Created https://redmine.pfsense.org/issues/4747 for the lack of sanity checking.

firewalluser

@doktornotor:

TL;DR

Dude when you don't specify any upstream DNS servers there's nothing to forward to. PERIOD. Severe case of PEBKAC.

I'm not familiar with the phrase PEBKAC? Care to explain?

WRT the topic, I'll add the static IP address to the DNS fields in General Settings as per your suggestion then, give it a reboot and will see what happens, whilst ignoring

Allow DNS to be overridden by DHCP/PPP on Wan is ticked (opposite to 1st fw).
Do not use the DNS Forwarder as DNS Server is ticked (opposite to 1st fw).

I'll post my findings when I've had something to eat as well so I wont BRB. ;)

KOM

I'm not familiar with the phrase PEBKAC? Care to explain?

Problem Exists Between Keyboard And Chair

firewalluser

@doktornotor:

TL;DR

Dude when you don't specify any upstream DNS servers there's nothing to forward to. PERIOD. Severe case of PEBKAC.

EDIT: Created https://redmine.pfsense.org/issues/4747 for the lack of sanity checking.

Ok, so I left all the other settings as they were before but have added in the 2nd fw the static ip address of the 1st fw in the System: General Setip, DNS Servers fields and left the gw blank.

This time, it initially during the boot process talks to the 1st fw's DNS server, but then proceeds to talk to the root servers again whilst the boot process finishes?

Next test, same as above but this time I specify the gw in the drop down as the only difference.

Same results, initially it talks to the 1st fw's DNS server, then it proceeds to talk to the root servers again.

So do you know what other setting changes I should make to the 2nd fw in order to stop unbound/DNS Resolver from talking to the root-servers.net and just use the DNS servers from the 1st fw?

I still havent found any reason for the capitalised G & M.root-servers.net though, but I have not packet captured them to see if they go out on the net like that or not.

It certainly seems odd to see some of the root server ip addresses resolved in capitals when the others are all lowercase in the pfsense fw logs though.

@KOM:

I'm not familiar with the phrase PEBKAC? Care to explain?

Problem Exists Between Keyboard And Chair

RIC

SWIM calls them Computer User(s) Non Technical. ::)

doktornotor

@firewalluser:

Same results, initially it talks to the 1st fw's DNS server, then it proceeds to talk to the root servers again.

When you have this set to

Outgoing Network Interfaces = Wan only

then it's hardly surprising it won't query another FW on your LAN or god knows where. Sigh.

@firewalluser:

So do you know what other setting changes I should make to the 2nd fw in order to stop unbound/DNS Resolver from talking to the root-servers.net and just use the DNS servers from the 1st fw?

Sure. Disable the DNS Resolver and kindly use the fine DNS Forwarder. It's there for exactly this purpose, plus won't overwhelm you with settings – preventing you from creating stupid configurations and shooting yourself into the foot repeatedly.

@firewalluser:

I still havent found any reason for the capitalised G & M.root-servers.net though, but I have not packet captured them to see if they go out on the net like that or not.

No, they do not go OUT like that. They come BACK like that when you resolve the PTR of the root server's IP address. Get some more tinfoil.

P.S. Kindly post a screenshot of the freaking settting if you are going to "debug" your "issues" in future. Absolutely NOT interested in wading through the messy descriptions.

firewalluser

@doktornotor:

@firewalluser:

Same results, initially it talks to the 1st fw's DNS server, then it proceeds to talk to the root servers again.

When you have this set to

Outgoing Network Interfaces = Wan only

then it's hardly surprising it won't query another FW on your LAN or god knows where. Sigh.

Maybe I didnt explain how its laid out properly.

Internet –>fw1---->fw2---->Lan
fw1 runs unbound
fw2 runs unbound and I know I could run the forwarder here as I could also do on fw1.

@firewalluser:

So do you know what other setting changes I should make to the 2nd fw in order to stop unbound/DNS Resolver from talking to the root-servers.net and just use the DNS servers from the 1st fw?

Sure. Disable the DNS Resolver and kindly use the fine DNS Forwarder. It's there for exactly this purpose, plus won't overwhelm you with settings – preventing you from creating stupid configurations and shooting yourself into the foot repeatedly.

Well I'll give this a go tomorrow now, but I wanted to keep unbound in the loop as this is running on the main fw anyway and I'm trying to establish the states not blocking or rejecting properly in my other post.

In order to test/debug anything, its generally recognised the environment/settings are kept as identical as possible when trying to recreate problems.

I didnt think unbound would for some unexplained reason so far, still insist on talking with the root-servers unless maybe there is a bug somewhere in pfsense or the unbound package or incorrect settings. Despite your settings, unbound still insists on talking to the root-servers at which point you suggest using the forwarder.

@firewalluser:

I still havent found any reason for the capitalised G & M.root-servers.net though, but I have not packet captured them to see if they go out on the net like that or not.

No, they do not go OUT like that. They come BACK like that when you resolve the PTR of the root server's IP address. Get some more tinfoil.

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

P.S. Kindly post a screenshot of the freaking settting if you are going to "debug" your "issues" in future. Absolutely NOT interested in wading through the messy descriptions.

Sure.

@doktornotor:

Are you on LSD? The only thing I modified here was moving the 0x20 P.S. to a new post – since you meanwhile posted another post.

In response to the above, I've been thinking about this, hypothetically speaking, if I was subjected to a MITM attack with code injection changing what you had typed when I saw it earlier today, this is not unlike SQL Injection when taking down/over SQL Servers, & we know MITM is possible when considering this coincidental post from earlier today. https://forum.pfsense.org/index.php?topic=94838.0

So with that in mind, it then prompted another question. How would we know ESF have not had their certs nicked?
How does one go about proving that little conundrum other than reissue some new ones and send out an alert?

I think its a pertinent question considering todays news about the US Govt employee db hack that goes back to 1985, it makes you wonder what the NSA are doing to protect their infrastructure and made me wonder about ESF servers which last time I checked was based in Texas.

I've still got other questions based on what you have said which seems to contradict my interpretation of the online docs but I'll see if we can actually get unbound to not talk with the root-servers first.

doktornotor

@firewalluser:

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

God almighty. Because whatever server your are quering for the PTR returns them like that. Period. And it's not even the LOG. It's the IP being RESOLVED in the WebGUI because you clicked the i to do so. Stop clicking there and the CAPS "pattern" won't bother you.

Out of this conspiracy idiocy, enough time wasted.

firewalluser

@doktornotor:

@firewalluser:

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

God almighty. Because whatever server your are quering for the PTR returns them like that. Period. And it's not even the LOG. It's the IP being RESOLVED in the WebGUI because you clicked the i to do so. Stop clicking there and the CAPS "pattern" won't bother you.

Out of this conspiracy idiocy, enough time wasted.

@doktornotor:

They are all capitalized. ftp://ftp.internic.net/domain/named.cache


 unbound-control -c /var/unbound/unbound.conf list_stubs
. IN stub prime M.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 2001:dc3::35 2001:500:3::42 2001:7fd::1 2001:503:c27::2:30 2001:7fe::53 2001:500:1::803f:235 2001:500:2f::f 2001:500:2d::d 2001:500:2::c 2001:500:84::b 2001:503:ba3e::2:30 202.12.27.33 199.7.83.42 193.0.14.129 192.58.128.30 192.36.148.17 128.63.2.53 192.112.36.4 192.5.5.241 192.203.230.10 199.7.91.13 192.33.4.12 192.228.79.201 198.41.0.4

As for patterns, try more thick tinfoil.

When I run unbound-control -c /var/unbound/unbound.conf list_stubs in the gui command prompt I see what you see, ie they are all capitalised on the 1st fw which is running unbound. I cant say about all the ipv6 addresses as they go off the screen, but the below is identical to what you have posted.


. IN stub prime M.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET.

I cant see any reason why a program code would selectively just capitalise the G & M root servers when the above command shows they are all capitalised and yet the system fw log in the gui, shows all the ip addresses I've looked at over and above the root server ip addresses as lower case. It doesnt seem logical. If you dont know, say so, I'll keep digging to find out why as it seems odd.

Edit. I should add to be clear I run this command on fw1, not the virtual fw2.

Derelict

On your pfSense you will find the drill command. It is from the same people who brought you unbound. Using it to find out which name servers are returning what values would be a good exercise in learning to use it.

(Are you just sitting around looking for shit to complain about?)

doktornotor

@firewalluser:

yet the system fw log in the gui

It's NOT in the fsckin' log. It's being resolved (!!!) by the webgui when you click the I icon… By the DNS server that happens to gets queried for the x.x.x.x.in-addr.arpa. Kindly do some Google on PTR/reverse DNS records, instead of this conspiracy bullshit.


# dig @8.8.8.8 33.27.12.202.in-addr.arpa ptr

; <<>> DiG 9.9.6-P1 <<>> @8.8.8.8 33.27.12.202.in-addr.arpa ptr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50919
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;33.27.12.202.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
33.27.12.202.in-addr.arpa. 939  IN      PTR     M.ROOT-SERVERS.NET.

;; Query time: 134 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jun 06 00:49:34 CEST 2015
;; MSG SIZE  rcvd: 86


# dig @192.168.0.151 33.27.12.202.in-addr.arpa ptr

; <<>> DiG 9.9.6-P1 <<>> @192.168.0.151 33.27.12.202.in-addr.arpa ptr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62637
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;33.27.12.202.in-addr.arpa.     IN      PTR

;; ANSWER SECTION:
33.27.12.202.in-addr.arpa. 86343 IN     PTR     m.root-servers.net.

;; Query time: 2 msec
;; SERVER: 192.168.0.151#53(192.168.0.151)
;; WHEN: Sat Jun 06 00:50:19 CEST 2015
;; MSG SIZE  rcvd: 86


# dig @8.8.8.8 4.0.41.198.in-addr.arpa ptr

; <<>> DiG 9.9.6-P1 <<>> @8.8.8.8 4.0.41.198.in-addr.arpa ptr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38883
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;4.0.41.198.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
4.0.41.198.in-addr.arpa. 86     IN      PTR     a.root-servers.net.

;; Query time: 127 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sat Jun 06 00:55:01 CEST 2015
;; MSG SIZE  rcvd: 84

What you see is the reply from the DNS server. There's no conspiracy shit nor hidden code nor any similar bullcrap in pfSense! Go ask the admin of the DNS server that you are hitting why they "pattern" with CAPS. Hopefully they'll send some medication to you. >:( >:( >:(


;; AUTHORITY SECTION:
27.12.202.in-addr.arpa. 85809   IN      NS      mango.itojun.org.
27.12.202.in-addr.arpa. 85809   IN      NS      ns-wide.wide.ad.jp.
27.12.202.in-addr.arpa. 85809   IN      NS      ns.tokyo.wide.ad.jp.

jahonix

@doktornotor:

I have better things to do with my life than investigating absolutely irrelevant nonsense.

Obviously.
That's why you are still posting in this thread a couple hours later. ::)

NOYB

@doktornotor:

… I have better things to do with my life than investigating absolutely irrelevant nonsense.

Wish you would go do them instead of carrying on a thread about "absolutely irrelevant nonsense" so that you can make snide remarks.

firewalluser

@doktornotor:

@firewalluser:

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

God almighty. Because whatever server your are quering for the PTR returns them like that. Period. And it's not even the LOG. It's the IP being RESOLVED in the WebGUI because you clicked the i to do so. Stop clicking there and the CAPS "pattern" won't bother you.

Out of this conspiracy idiocy, enough time wasted.

Trying to find out which server this is at the moment, unbound had a 3 hour fart yesterday after making some innocuous changes yesterday so I gave up getting online, although I was always under the impression all url's were lower case, I must have missed when upper case was allowed or I was supplied incorrect data originally.

Anyway still havent found a way to stop unbound from talking to the root-servers.net or even why I get supplied different root-servers.net to you, so looking through the online unbound information now as ip address permutations are quite variable and sometimes quite unique in some circumstances which generates its own patterns but not LSD related. ;)

I appreciate your perseverance. :)

@NOYB:
@jahonix:

This is educational for sock puppet training. :D

Derelict

JFC. FQDNs are case-insensitive. You guys are on tilt. Get over yourselves.

Derelict

@firewalluser:

@doktornotor:

@firewalluser:

I'm not saying they go out like that, I'm asking why do those two appear capitalised in the pfsense fw logs?

God almighty. Because whatever server your are quering for the PTR returns them like that. Period. And it's not even the LOG. It's the IP being RESOLVED in the WebGUI because you clicked the i to do so. Stop clicking there and the CAPS "pattern" won't bother you.

Out of this conspiracy idiocy, enough time wasted.

Trying to find out which server this is at the moment, unbound had a 3 hour fart yesterday after making some innocuous changes yesterday so I gave up getting online, although I was always under the impression all url's were lower case, I must have missed when upper case was allowed or I was supplied incorrect data originally.

Anyway still havent found a way to stop unbound from talking to the root-servers.net or even why I get supplied different root-servers.net to you, so looking through the online unbound information now as ip address permutations are quite variable and sometimes quite unique in some circumstances which generates its own patterns but not LSD related. ;)

I appreciate your perseverance. :)

@NOYB:
@jahonix:

This is educational for sock puppet training. :D

DNS and BIND. Liu and Albitz.

Buy it. Read it. Learn it. Live it. Else piss the fuck off.

NOYB

@firewalluser:

… I was always under the impression all url's were lower case, I must have missed when upper case was allowed or I was supplied incorrect data originally.

Domain names have always (or at least for a very long time) been case insensitive. Any particular usage of them is free to change or maintain their case.

Case sensitivity of the path portion of URL's is dependent upon the web server.
For instance Apache on a Linux machine will probably be case sensitive. IIS on a Windows machine probably case insensitive.

Derelict

Case sensitivity on the web server is not DNS. DNS is case-insensitive. Read the goddamn RFC.

NOYB

@Derelict:

Case sensitivity on the web server is not DNS. DNS is case-insensitive. Read the goddamn RFC.

I know. But someone brought URL into the conversation so thought I point it out.