GSS-TSIG / nsupdate -g problems

2010-04-23 Thread Phil Mayers

All,

We have an Active Directory environment here, but use bind9 as our DNS 
servers. We have for years delegated out the zones:


_tcp.ic.ac.uk
_udp.ic.ac.uk

...and so forth, and used "allow-update" from the IPs of the AD servers.

We're moving to DNSSEC-sign our zones shortly and I though I might take 
the opportunity to move to using GSS-TSIG and update-policy, and merge 
these zones back in (and get them signed without the complication of a 
DS record)


However I can't seem to get even a basic test setup running. I've 
managed to puzzle out the exact syntax required in "named.conf" (yay - 
case-sensitive GSS principle parsing, how helpful) but "nsupdate -g" 
seems to simply not work, telling me:


buildquery error
dns_tkey_buildgssquery failed: ran out of space

...or with more debugging:

setup_system()
reset_system()
user_interaction()
get_next_command()
get_next_command()
get_next_command()
evaluate_update()
update_addordelete()
get_next_command()
start_update()
recvsoa()
About to create rcvmsg
show_message()
Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  65231
;; flags: qr aa ra ; QUESTION: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;ic.ac.uk.  IN  SOA

;; ANSWER SECTION:
ic.ac.uk.		86400	IN	SOA	mname.ic.ac.uk. hostmaster.ic.ac.uk. 2006404671 
2700 1800 360 86400


;; AUTHORITY SECTION:
ic.ac.uk.   86400   IN  NS  mname.ic.ac.uk.

;; ADDITIONAL SECTION:
mname.ic.ac.uk. 86400   IN  A   192.168.1.1

Found zone name: ic.ac.uk
The master is: mname.ic.ac.uk
start_gssrequest
buildquery error
dns_tkey_buildgssquery failed: ran out of space


I do have an appropriate krb5.conf and indeed the kerberos ticket cache 
lists a valid-looking ticket:


04/23/10 14:45:57  04/24/10 00:45:40  DNS/mname.ic.ac...@ic.ac.uk
renew until 04/24/10 00:45:35, Flags: FRA
Etype (skey, tkt): ArcFour with HMAC/md5, ArcFour with HMAC/md5
Addresses: (none)

Does anyone have any suggestions?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


one record to be redirected to a specific IP

2010-04-23 Thread hugo hugoo

Hello all,

 

I plan to use BIND as caching DNS.

But I need to could redirect a specific record to a specific IP.

 

How can I do this?

 

This redirection must only be applied for one record.

 

Ex:   a query for www.ABCD.com must be answered by the IP I have choosen.

 

The redirection must not be applied on all the domain ABCD.COM

 

 

Can you help?

Can you give an example of config file to do this?

 

 

Thanks in advance,

 

Hugo,

 
  
_
Surfez en toute sécurité: téléchargez Internet Explorer 8
http://www.microsoft.com/belux/fr/windows/internet-explorer/___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [ga] Re: Resolving .gov w/dnssec

2010-04-23 Thread Joe Baptista
On Fri, Apr 23, 2010 at 12:15 AM, Hugh Dierker wrote:

> Fair trade is necessary trade. Unnecessary tradeoffs are lame.
>

I agree. It is a tradeoff and not fair trade.


> These problems are not necessary -- except that they are within the given
> framework of lack of motivation to do better.  It comes down to this, if we
> set our standards outside of competitive models there is no incentive to do
> better.  ICANN, the Dnssec and this SAIC are working within government
> sanctioned slobbery, both intellectual and economic slobbery.  I used to
> think it was snobbery, now I know it is a laziness born of shovel leaning
> bureaucrats. You may be kind and call it "make work" but would you call
> intentional fraud "make work"? Buggy whips and Railroad fireman is what this
> is.
>

Again I agree. DNSSEC is a snow job by committee.  SAIC is a joke.  "I" root
server in Beijing is still down. Where is SAIC on that.


>
> The plan I am putting together for the inculsives will generate some new
> fire under the pants of these obstructionists and they will find that a
> better mousetrap can be built.
>

Thank you - I and my TLD holders thank you.

regards
joe baptista



>
>
>
> --- On *Thu, 4/22/10, Joe Baptista * wrote:
>
>
> From: Joe Baptista 
> Subject: [ga] Re: Resolving .gov w/dnssec
> To: c...@cam.ac.uk, "g...@gnso.icann.org >> GA" 
> Cc: "Paul Wouters" , "Bind Users Mailing List" <
> bind-users@lists.isc.org>, "Timothe Litt" 
> Date: Thursday, April 22, 2010, 8:07 AM
>
> Looks like the future of the DNSSEC make work project includes resolution
> failures here and there. More security - less stability - guaranteed
> slavery. I wounder if it's a fair trade.
>
> we'll see ..
> regards
> joe baptista
>
> On Thu, Apr 22, 2010 at 10:52 AM, Chris Thompson 
> http://us.mc529.mail.yahoo.com/mc/compose?to=c...@cam.ac.uk>
> > wrote:
>
>> On Apr 22 2010, Paul Wouters wrote:
>>
>> On Thu, 22 Apr 2010, Timothe Litt wrote:
>>>
>>> I'm having trouble resolving uspto.gov with bind 9.6.1-P3 and 9.6-ESV
 configured as valdidating resolvers.

 Using dig, I get a connection timeout error after a long (~10 sec)
 delay.
 +cdflag provides an immediate response.

>>>
>>> Is anyone else seeing this?  Ideas on how to troubleshoot?

>>>
>>> I have the same problems with our validating unbound instance.
>>>
>>
>> I suspect that this has to do with
>>
>>  dig +dnssec +norec dnskey uspto.gov @dns1.uspto.gov.
>>  dig +dnssec +norec dnskey uspto.gov @sns2.uspto.gov.
>>
>> failing with timeouts, while   dig +dnssec +norec +vc dnskey uspto.gov @
>> dns1.uspto.gov.
>>  dig +dnssec +norec +vc dnskey uspto.gov @dns2.uspto.gov.
>>
>> work fine ... with a 1736-byte answer. Probably the fragmented
>> UDP response is getting lost somewhere near the authoritative
>> servers themselves.
>>
>> --
>> Chris Thompson
>> Email: 
>> c...@cam.ac.uk
>>
>>
>> ___
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
>>
>
>
>
>


-- 
Joe Baptista

www.publicroot.org
PublicRoot Consortium

The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.

 Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084

Personal: http://baptista.cynikal.net/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Resolving .gov w/dnssec

2010-04-23 Thread Michael Sinatra

On 04/22/10 18:48, Timothe Litt wrote:

I get a "connection timed out; no servers could be reached" after the
"Truncated, retrying in TCP mode" even with +bufsiz=512


I get a correct response when I use +bufsiz=512.  After "Truncated, 
retrying in TCP mode" I get a response, but apparently you don't.



I am not blocking tcp/53. In fact, telnet dns1.uspto.gov 53 will happily
establish a connection :-) I'm on a fiber (Verizon FiOS business)
circuit - given that others are seeing this over a wide geography, seems
like the investigation needs to start closer to the .gov servers...


Certainly for the UDP fragmentation issue that's true.  Everyone seems 
to be having that problem.  But you seem to be the only one having the 
problem where you can't receive TCP even if you set a low bufsize.  I 
can fallback to TCP just fine as long as I set a low bufsize.



If you're into numerology, 1736 is 1500 + 236 -- with a 20 byte header
on the 236, you get 256 for the fragement - which is mildly curious.
Folks on DSL should remember that their magic number is less than 1500
bytes (1492 is common, as is 1453).


...which makes me think that there is a PMTUD issue in your situation. 
You can establish a TCP connection, but perhaps you receive a larger 
packet than you can actually receive and you can't signal that you can't 
receive such a packet because someone is blocking ICMP on the path 
between you and uspto.gov.  Only a packet trace will even begin to yield 
some clues there.


*If* that's true, that, combined with the UDP fragment blockage just 
makes me think: "My, how we've gunked up the Internet."


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


Re: one record to be redirected to a specific IP

2010-04-23 Thread Doug Barton
On 04/23/10 08:15, hugo hugoo wrote:
> Hello all,
>  
> I plan to use BIND as caching DNS.
> But I need to could redirect a specific record to a specific IP.
>  
> How can I do this?
>  
> This redirection must only be applied for one record.
>  
> Ex:   a query for www.ABCD.com  must be answered by
> the IP I have choosen.
>  
> The redirection must not be applied on all the domain ABCD.COM
>  
>  
> Can you help?
> Can you give an example of config file to do this?

You need to create a zone for just that record.

In named.conf:
zone "www.abcd.com" {
type master;
file "/etc/namedb/master/www.abcd.com";
};

For the file line above replace the path to indicate where your actual
zone files are stored.

In the zone file, you would do this:
$TTL 3h
www.abcd.com. SOA localhost. nobody.localhost. 42 1d 12h 1w 10m
; Serial, Refresh, Retry, Expire, Neg. cache TTL

NS  localhost.
A   1.2.3.4


Hope this helps,

Doug


-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

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


error (network unreachable)

2010-04-23 Thread ic.nssip
Hello everyone,

I just enabled querylog (using rndc querylog command) and each first query 
logged it's coming with errors (network unreachable) when trying to resolve dns 
servers names.

Has anyone any idea where from this sort of message is coming from and what 
should I do to get it fixed?

Thank you,
Julian

p.s. Here is a little capture from syslog showing the errors for 3 queries I 
sent to my DNS Server:

Apr 23 15:17:26 snowbird.nwtel.com named[2520]: [ID 873579 daemon.info] client 
216.126.115.58#34096: query: www.google.com IN A + (216.126.115.58)
Apr 23 15:17:26 snowbird.nwtel.com named[2520]: [ID 873579 daemon.info] error 
(network unreachable) resolving 'www.google.com/A/IN': 
2001:503:a83e::2:30#53Apr 23 15:21:50 ns.domain.com named[2520]: [ID 873579 
daemon.info] client 216.126.115.58#34154: query: www.nwtel.ca IN A + 
(216.126.115.58)Apr 23 15:21:50 ns.domain.com named[2520]: [ID 873579 
daemon.info] error (network unreachable) resolving 
'great-bear.northwestel.net//IN': 2001:503:a83e::2:30#53Apr 23 15:32:02 
ns.domain.com named[2676]: [ID 873579 daemon.info] client 216.126.115.58#34278: 
query: www.cnn.com IN A + (216.126.115.58)Apr 23 15:32:02 ns.domain.com 
named[2676]: [ID 873579 daemon.info] error (network unreachable) resolving 
'ns1.timewarner.net/A/IN': 2001:7fd::1#53Apr 23 15:32:02 ns.domain.com 
named[2676]: [ID 873579 daemon.info] error (network unreachable) resolving 
'ns3.timewarner.net/A/IN': 2001:500:3::42#53Apr 23 15:32:02 ns.domain.com 
named[2676]: [ID 873579 daemon.info] error (network unreachable) resolving 
'ns5.timewarner.net//IN': 2001:dc3::35#53Apr 23 15:32:02 ns.domain.com 
named[2676]: [ID 873579 daemon.info] error (network unreachable) resolving 
'ns1.timewarner.net/A/IN': 2001:dc3::35#53Apr 23 15:32:02 ns.domain.com 
named[2676]: [ID 873579 daemon.info] error (network unreachable) resolving 
'ns1.timewarner.net/A/IN': 2001:500:1::803f:235#53Apr 23 15:32:02 ns.domain.com 
named[2676]: [ID 873579 daemon.info] error (network unreachable) resolving 
'ns3.timewarner.net/A/IN': 2001:500:1::803f:235#53Apr 23 15:32:02 ns.domain.com 
named[2676]: [ID 873579 daemon.info] error (network unreachable) resolving 
'ns3.timewarner.net/A/IN': 2001:503:c27::2:30#53Apr 23 15:32:02 ns.domain.com 
named[2676]: [ID 873579 daemon.info] error (network unreachable) resolving 
'ns5.timewarner.net//IN': 2001:503:c27::2:30#53Apr 23 15:32:02 
ns.domain.com named[2676]: [ID 873579 daemon.info] error (network unreachable) 
resolving 'ns5.timewarner.net//IN': 2001:500:2f::f#53Apr 23 15:32:02 
ns.domain.com named[2676]: [ID 873579 daemon.info] error (network unreachable) 
resolving 'ns1.timewarner.net/A/IN': 2001:503:c27::2:30#53Apr 23 15:32:02 
ns.domain.com named[2676]: [ID 873579 daemon.info] error (network unreachable) 
resolving 'ns3.timewarner.net//IN': 2001:503:a83e::2:30#53Apr 23 15:32:02 
ns.domain.com named[2676]: [ID 873579 daemon.info] error (network unreachable) 
resolving 'dmtns02.turner.com/A/IN': 2001:503:231d::2:30#53Apr 23 15:45:45 
ns.domain.com named[2676]: [ID 873579 daemon.info] client 216.126.115.58#34434: 
query: www.cnn.com IN A + (216.126.115.58)Apr 23 15:45:45 ns.domain.com 
named[2676]: [ID 873579 daemon.info] error (network unreachable) resolving 
'www.cnn.com/A/IN': 2001:503:231d::2:30#53___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: delegating subname.localdomain to 127.0.0.2 on the client machine?

2010-04-23 Thread Mark Hedges


On Wed, 21 Apr 2010, Barry Margolin wrote:
> >
> > The scenario is a farm of sendmail + RBL servers that
> > have independent management and databases, but a single
> > bind server.  Sendmail etc. would do a lookup of
> > 78.56.34.12.rbl.localdomain and it would look at
> > localhost on 127.0.0.2, where the local RBL service
> > listens.
>
> You need to run a caching nameserver on the sendmail
> machines, and point them to 127.0.0.1 in /etc/resolv.conf.
> The stub resolver doesn't follow delegations, it sends
> recursive queries and expects the server to do all the
> work.

Actually this is not working still.  Am I wasting my time?

rbldnsd listens on 127.0.0.2 and answers right when queried
directly for something like
1.139.214.85.countries.rbl.localdomain.

named listens on 127.0.0.1, set in /etc/resolv.conf, and
answers all other queries correctly, including
'horta.localdomain' set up in example below, so I know it is
reading in the zone file.

However, named will not delegate *.rbl.localdomain zones,
and gives NXDOMAIN.  Help?  Thanks --mark--

// named.conf
acl "localdomain" {
127.0.0.0/8;
};
options {
listen-on port 53 { 127.0.0.1; };
// listen-on-v6 port 53 { ::1; };
directory   "/var/named";
dump-file   "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";

// Those options should be used carefully because they disable port
// randomization
// query-sourceport 53;
// query-source-v6 port 53;

// our nameservers...
forwarders { 192.168.9.86; 192.168.9.35; };
allow-transfer  { localdomain; };
allow-recursion { localdomain; };
allow-query { localdomain; };
allow-query-cache   { localdomain; };
};
logging {
channel default_debug {
file "data/named.run";
severity debug;
};
};
view localhost_resolver {
match-clients  { localdomain; };
match-destinations { localdomain; };
recursion yes;
include "/etc/named.rfc1912.zones";
};

// named.rfc1912.zones excerpt:
zone "localdomain" IN {
type master;
file "localdomain.zone";
allow-update { none; };
};


# localdomain.zone
$TTL900
@   IN SOA  localhost root (
2010042302  ; serial
5m  ; refresh
5m  ; retry
30m ; expiry
5m  ; minimum cache
)
IN NS   localhost.localdomain.
IN NS   rbldnsd.localdomain.

localhost   IN A127.0.0.1

horta IN A 127.0.0.3

; delegate rbl zones to rbl localhost ip.
; rbl listens on 127.0.0.2 so this does not cause a lookup loop.
rbldnsd IN A127.0.0.2
rbl.localdomain.IN NS   rbldnsd.localdomain.
rbl.localdomain.IN A127.0.0.2

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