Re: return address for failed DNSSEC validation

2010-03-10 Thread imfel...@gmail.com 
Hi Gilles,

this question came up as well at a DNSSEC workshop I attended recently. IMHO 
redirecting to a website will cause similar misuse to what wildcard records 
have caused. One might argue a new RCODE would be the right thing but really, 
the SERVFAIL is actually correct. The server at the other end did actually fail 
by not passing DNSSEC validation. End users will get confused by this, but then 
there are plenty of other possibilities with and without DNS they may get 
confused about. I think providing help to them should be dealt with by the OS 
instead of bloating DNS. Upon return of any error by DNS (or any other 
subsystem) it can show them a useful, platform-dependent message how to fix it.

-mat



On Mar 10, 2010, at 10:31 PM, Gilles Massen wrote:

> Hello all,
> 
> If a the validation of a signed RR fails, the answer from the validating
> resolver to the requestor is SERVFAIL, if I understood correctly. To the
> average end user who isn't aware that DNS exists this translates to
> "it's broken". Possibly even "my ISP is broken" if the neighbor's ISP
> does not validate.
> 
> So wouldn't a be an interesting option to allow Bind to be configured to
> return an IP address in case of failed validation (if a A/ record
> was queried). This would allow the provider to set up a webpage with a
> small explanation on what went wrong.
> 
> The obvious limitation of this feature would be that it assumes
> internet=http, even though you could go as far as set up a few services
> reacting appropriately on that "fail-host". On the other hand it would
> allow to lessen the fear from the unexplainable failure and return
> something to a large part of the users (if only who is to blame).
> 
> Thoughts?
> 
> 
> Best regards,
> Gilles
> 
> 
> -- 
> Fondation RESTENA - DNS-LU
> 6, rue Coudenhove-Kalergi
> L-1359 Luxembourg
> tel: (+352) 424409
> fax: (+352) 422473
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: strange behaviour of resolving nameserver

2010-03-09 Thread imfel...@gmail.com 
Torsten,

ws.mobilecdn.verisign.com. doesn't answer for me either.

It's supposed to be authoritatively hosted here:

mobilecdn.verisign.com. 900 IN  NS  dns1-auth.m-qube.com.
mobilecdn.verisign.com. 900 IN  NS  dns2-auth.m-qube.com.

But neither of them answer an iterative query for me, be it a SOA for 
mobilecdn.verisign.com. or the ultimately desired ws.mobilecdn.verisign.com. 
Not sure this is really your fault, unless of course the '-auth' means only 
certain people are allowed to query.

-mat


On Mar 9, 2010, at 3:40 PM, Torsten wrote:

> Am Wed, 10 Mar 2010 00:44:46 +1100
> schrieb Mark Andrews :
> 
>> 
>> In message <20100309142153.016c7...@the-damian.de>, Torsten writes:
>>> Hi,
>>> 
>>> I'm a bit clueless about what's happening here exactly.
>>> I have a server (9.6.1-P3) that tries resolving
>>> ws.mobilecdn.verisign.com. Queries for this host permanently fail
>>> with SERVFAIL.
>>> 
>>> I've narrowed the problem down to answers from c2.nstld.net 
>>> 
>>> 
>>> dig @c2.nstld.com mobilecdn.verisign.com 
>>> ;; Got referral reply from 192.26.92.31, trying next server
>> 
>> Fix /etc/resolv.conf to point to recursive nameservers.  192.26.92.31
>> is not a recursive nameserver.
> 
> /etc/resolv.conf already points to recursive nameservers. Since these
> nameservers can't resolve ws.mobilecdn.verisign.com I tried every
> single nameserver found by dig +trace and ended up with the behaviour
> of c2.nstld.net.
> 
>> 
>>> ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.1 <<>> @c2.nstld.com
>>> mobilecdn.verisign.com ; (2 servers found)
>>> ;; global options:  printcmd
>>> ;; connection timed out; no servers could be reached
>>> 
>>> 
>>> This happens only if the hostname is used in a dig. Using the ipv4
>>> address everything turns out fine.
>>> 
>>> What's even more strange is the answer packet received (at least I
>>> can't see any errors there).
>>> 
>>> 
>>> No. TimeSourceDestination
>>> Protocol Info 4 3.529927192.26.92.31  10.10.3.22
>>> DNS  Standard query response
>>> 
>>> Frame 4 (140 bytes on wire, 140 bytes captured)
>>>Arrival Time: Mar  9, 2010 13:33:49.987181000
>>>[Time delta from previous captured frame: 0.086282000 seconds]
>>>[Time delta from previous displayed frame: 0.086282000 seconds]
>>>[Time since reference or first frame: 3.529927000 seconds]
>>>Frame Number: 4
>>>Frame Length: 140 bytes
>>>Capture Length: 140 bytes
>>>[Frame is marked: True]
>>>[Protocols in frame: eth:ip:udp:dns]
>>>[Coloring Rule Name: UDP]
>>>[Coloring Rule String: udp]
>>> Ethernet II, Src: Cisco_46:45:d3 (00:04:27:46:45:d3), Dst:
>>> HewlettP_08:78:76 (00:1f:29:08:78:76) Destination: HewlettP_08:78:76
>>> (00:1f:29:08:78:76) Address: HewlettP_08:78:76 (00:1f:29:08:78:76)
>>> ...0     = IG bit: Individual address
>>> (unicast)  ..0.     = LG bit: Globally unique
>>> address (factory default) Source: Cisco_46:45:d3 (00:04:27:46:45:d3)
>>>Address: Cisco_46:45:d3 (00:04:27:46:45:d3)
>>> ...0     = IG bit: Individual address
>>> (unicast)  ..0.     = LG bit: Globally unique
>>> address (factory default) Type: IP (0x0800)
>>> Internet Protocol, Src: 192.26.92.31 (192.26.92.31), Dst: 10.10.3.22
>>> (10.10.3.22) Version: 4
>>>Header length: 20 bytes
>>>Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN:
>>> 0x00)  00.. = Differentiated Services Codepoint: Default (0x00)
>>> ..0. = ECN-Capable Transport (ECT): 0
>>> ...0 = ECN-CE: 0
>>>Total Length: 126
>>>Identification: 0x (0)
>>>Flags: 0x02 (Don't Fragment)
>>>0.. = Reserved bit: Not Set
>>>.1. = Don't fragment: Set
>>>..0 = More fragments: Not Set
>>>Fragment offset: 0
>>>Time to live: 58
>>>Protocol: UDP (0x11)
>>>Header checksum: 0x1716 [correct]
>>>[Good: True]
>>>[Bad : False]
>>>Source: 192.26.92.31 (192.26.92.31)
>>>Destination: 10.10.3.22 (10.10.3.22)
>>> User Datagram Protocol, Src Port: domain (53), Dst Port: 48885
>>> (48885) Source port: domain (53)
>>>Destination port: 48885 (48885)
>>>Length: 106
>>>Checksum: 0x1190 [validation disabled]
>>>[Good Checksum: False]
>>>[Bad Checksum: False]
>>> Domain Name System (response)
>>>[Request In: 3]
>>>[Time: 0.086282000 seconds]
>>>Transaction ID: 0x3824
>>>Flags: 0x8100 (Standard query response, No error)
>>>1...    = Response: Message is a response
>>>.000 0...   = Opcode: Standard query (0)
>>> .0..   = Authoritative: Server is not an
>>> authority for domain  ..0.   = Truncated: Message is
>>> not truncated  ...1   = Recursion desired: Do query
>>> recursively   0...  = Recursion available: Server can't
>>> do recursive queries

Re: Recursing only for white listed domains

2010-03-08 Thread imfel...@gmail.com 
Hi,

For whitelisting a set of domains via their netblocks to allow recursion FROM 
them, the allow-recursion statement is your friend. For a filtering setup, 
which I think is what you want to achieve, a web proxy is much more suitable. 
An internal root would allow you to such things via DNS, but if you had that, 
you're likely to have web proxies as well.

Regards,

-mat


On Mar 8, 2010, at 8:29 PM, Joe User wrote:

> Hi, I would like to implement a server for an internal business business unit 
> to restrict recusion for only domains white listed by IT. Can anyone share a 
> config for a similar implementation.
> 
> thanks
> Tom
> 
> 
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users