Strange resolver problem



  • Hi,

    I'm having a strange problem. DNS Resolver service is on, and everything works. Well, almost everything.

    Any query resolving to an IP belonging to any of the LAN addressings, is returned empty.

    Example:

    fibra.xxx.xxx resolves to 81.47.17.21 (public IP answer)
    sonar.xxx.xxx resolves to 172.26.10.190 (private IP answer)
    test.xxx.xxx resolves to 172.26.3.5 (private IP answer)

    172.26.10.0/24 is a /24 in an OPT interface
    172.26.3.5 is a /24 in a VLAN interface

    
    [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig fibra.xxx.xxx 
    
    ; <<>> DiG 9.10.4-P2 <<>> fibra.xxx.xxx
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31824
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;fibra.xxx.xxx.           IN      A
    
    ;; ANSWER SECTION:
    fibra.xxx.xxx.    45      IN      A       81.47.17.21
    
    ;; AUTHORITY SECTION:
    xxx.xxx.          171269  IN      NS      ns-1257.awsdns-29.org.
    xxx.xxx.          171269  IN      NS      ns-1647.awsdns-13.co.uk.
    xxx.xxx.          171269  IN      NS      ns-474.awsdns-59.com.
    xxx.xxx.          171269  IN      NS      ns-783.awsdns-33.net.
    
    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Mon Oct 24 19:04:31 CEST 2016
    ;; MSG SIZE  rcvd: 201
    
    [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig sonar.xxx.xxx  
    
    ; <<>> DiG 9.10.4-P2 <<>> sonar.xxx.xxx
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26372
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;sonar.xxx.xxx.           IN      A
    
    ;; AUTHORITY SECTION:
    xxx.xxx.          171263  IN      NS      ns-1257.awsdns-29.org.
    xxx.xxx.          171263  IN      NS      ns-1647.awsdns-13.co.uk.
    xxx.xxx.          171263  IN      NS      ns-474.awsdns-59.com.
    xxx.xxx.          171263  IN      NS      ns-783.awsdns-33.net.
    
    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Mon Oct 24 19:04:37 CEST 2016
    ;; MSG SIZE  rcvd: 185
    
    [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig test.xxx.xxx     
    
    ; <<>> DiG 9.10.4-P2 <<>> test.xxx.xxx
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45889
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;test.xxx.xxx.            IN      A
    
    ;; AUTHORITY SECTION:
    xxx.xxx.          171258  IN      NS      ns-1257.awsdns-29.org.
    xxx.xxx.          171258  IN      NS      ns-1647.awsdns-13.co.uk.
    xxx.xxx.          171258  IN      NS      ns-474.awsdns-59.com.
    xxx.xxx.          171258  IN      NS      ns-783.awsdns-33.net.
    
    ;; Query time: 122 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Mon Oct 24 19:04:42 CEST 2016
    ;; MSG SIZE  rcvd: 184
    
    [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: 
    
    

    If I use G's resolvers:

    
    [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig @8.8.8.8 sonar.xxx.xxx
    
    ; <<>> DiG 9.10.4-P2 <<>> @8.8.8.8 sonar.xxx.xxx
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 736
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;sonar.xxx.xxx.           IN      A
    
    ;; ANSWER SECTION:
    sonar.xxx.xxx.    299     IN      A       172.26.10.190
    
    ;; Query time: 52 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Mon Oct 24 19:05:28 CEST 2016
    ;; MSG SIZE  rcvd: 64
    
    [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: dig @8.8.8.8 test.xxx.xxx
    
    ; <<>> DiG 9.10.4-P2 <<>> @8.8.8.8 test.xxx.xxx
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20296
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    
    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;test.xxx.xxx.            IN      A
    
    ;; ANSWER SECTION:
    test.xxx.xxx.     299     IN      A       172.26.3.5
    
    ;; Query time: 49 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Mon Oct 24 19:05:33 CEST 2016
    ;; MSG SIZE  rcvd: 63
    
    [2.3.2-RELEASE][root@pfSense1.xxx.xxx]/root: 
    
    

    Any thoughts? I'm doing the DNS queries for this question from the firewall itself, but it happens the same no matter from where I make the queries.

    Thanks,

    Rubén.


  • Rebel Alliance Developer Netgate

    That is the default behavior by design. Accepting private IP address responses from public DNS servers allows DNS Rebinding attacks, so those responses are dropped.

    You can disable or work around this behavior as needed: https://doc.pfsense.org/index.php/DNS_Rebinding_Protections



  • ;) Thanks a lot sir.

    Rubén.


  • Rebel Alliance Global Moderator

    Having some public NS respond with private IP is BORKED.. the proper solution would not to return rfc1918 space from a public NS.

    Now if the NS returning it is not really public and only upstream from unbound running on pfsense, then sure you can work around this by disable of rebind or setting private domain.

    But if this NS is on the public internet an anyone on the internet can query it - returning rfc1918 is borked.



  • @johnpoz:

    Having some public NS respond with private IP is BORKED.. the proper solution would not to return rfc1918 space from a public NS.

    Now if the NS returning it is not really public and only upstream from unbound running on pfsense, then sure you can work around this by disable of rebind or setting private domain.

    But if this NS is on the public internet an anyone on the internet can query it - returning rfc1918 is borked.

    Well, that's a matter of oppinion, configuration and usage. We have a pair of domains we only use for internal apps and their entries are never seen/used outside our development/staging environments. Yes, I could set up private resolvers, but it's not worth the effort.

    Rubén.


  • Rebel Alliance Global Moderator

    The opinion would be that of everyone in the field..  Public dns is not for rfc1918 space..  As mentioned this is how rebinding attacks happen!

    https://tools.ietf.org/html/draft-ietf-dnsop-dontpublish-unreachable-03

    You sure and the hell can not do PTR for rfc1918 space in the public space..

    Not worth the effort??  And you wonder why you have problems..



  • Well, I was coming from a previous (2.1) pfsense version and didn't have the time to review all changes in detail. Anyway you guys are right, thanks.

    Rubén.