Bug or lack of description in webgui dns lookup?

johnpoz

So in another thread there has been discussion of pfsense not doing single label queries to MS dns, etc.. Not related to this request for confirmation from someone else or discussion of working as designed or not?

So the web gui dns lookup tool on 2.2.4 states
The DNS Lookup page at Diagnostics > DNS Lookup performs a quick DNS lookup of a hostname to IP address or vice versa.

While if you do a query to pfsense either dnsmasq or unbound with local records.. This seems to work just fine, put in an IP and get a response with the name. But if your doing a query to external dns, the query is not a correctly formatted PTR but a A record of the IP address. This would normally not return anything.

Shouldn't the tool when detecting an IP in the box correctly format a PTR query in the form of 5.2.0.192.in-addr.arpa vs the A record query it seems to be doing.

See example.. Query for IP 1.2.3.4 is an A query (left side of pic), while if you say on the firewall log click the little i on an IP address to have it resolve that IP it does a correct PTR query (right side)

wrongquerytype.png_thumb

doktornotor

I cannot recall this working ever since 2.2… Not sure if there's a bug filed somewhere or not.

johnpoz

I almost never use this took, I just do a dig from cmd line when I need to do a dns query.. But yeah this seems broken doesn't it - shouldn't it do a PTR.. How else would it expect to lookup fqdn from an IP?

doktornotor

Yeah, I'm not using it either since I found it doesn't produce any useful info. Just occasionally click it by accident to find that it still does not work. :D

cmb

I don't see any situation where it doesn't work. It sends both PTR and A queries when you enter an IPv4 IP.

The fact it sends A queries for IPv4 IPs is because an IPv4 IP is technically possibly a valid FQDN, numbers with dots in between could be a FQDN. It does a PTR lookup where is_ipaddr is true, then does an A lookup if is_hostname is true. You might not see the PTR lookup on subsequent attempts in tcpdump as it may be cached and it doesn't cache NXDOMAIN so you'll see the A, but the fact it shows the PTR on the page proves it did one.

doktornotor

@cmb:

The fact it sends A queries for IPv4 IPs is because an IPv4 IP is technically possibly a valid FQDN

Yeah. This "technically" made the is_hostname() thing completely useless. It "validates" complete crap. Suspect that's the real cause of "it doesn't work".

cmb

@doktornotor:

Yeah. This "technically" made the is_hostname() thing completely useless. It "validates" complete crap.

Validating hostnames that are valid per specs isn't "complete crap". What do you suggest, not accepting an IPv4 IP in is_hostname? Not necessarily a bad idea even if that would be technically wrong. I can't think of anything that's actually hurting though.

@doktornotor:

Suspect that's the real cause of "it doesn't work".

No one's shown anything here that doesn't work.

johnpoz

thanks cmb, I see that it sends PTR as well as the A now.. before it must of been neg cached.

As to say for example 1.2.7 being a valid A record?? Come on where? What # is a valid tld?? While you could use say 1.2.3.com as valid fqdn A record.. when did they allow for numbers "only" in a tld?

http://data.iana.org/TLD/tlds-alpha-by-domain.txt

I see the XN stuff stuff punycode versions of the unicode domains..

XN–11B4C3D
XN--1QQW23A
XN--30RR7Y
XN--3BST00M
XN--3DS443G
XN--3E0B707E
XN--3PXU8K
XN--42C2D9A
XN--45BRJ9C

etc.. but I do not see any sort of pure number based tld like .666 ;)

But now that I see it does send the valid PTR.. guess it works as designed so that answers my question - Thanks!

Iseeptrnow.png_thumb

doktornotor

@cmb:

Validating hostnames that are valid per specs isn't "complete crap". What do you suggest, not accepting an IPv4 IP in is_hostname? Not necessarily a bad idea even if that would be technically wrong.

Well, basically returning that to before what Phil (?) did - at least unless you call the function with an argument like relaxed or (sic!) rfc set to true - would certainly make it whole lot more useful again. As johnpoz noted, it takes completely whacky stuff ATM. Things like 1.2.7 being an example.

Or - to put it in a different way: Certainly recall I have been doing useful results with this and other similar features in 2.1.x. My understanding is – these places have logic that relies on only "sane" things being considered valid, in order to get things done in properly/in the right order/whatever. Once "insane" things are considered valid all of a sudden, things no longer make sense and it breaks.

I understand certain features need it more flexible (or, per the broken RFC specs), however what has been done has made this useless for most other stuff.