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

2010-04-23 Thread Joe Baptista
On Fri, Apr 23, 2010 at 12:15 AM, Hugh Dierker hdierker2...@yahoo.comwrote:

 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 bapti...@publicroot.org* wrote:


 From: Joe Baptista bapti...@publicroot.org
 Subject: [ga] Re: Resolving .gov w/dnssec
 To: c...@cam.ac.uk, g...@gnso.icann.org  GA g...@gnso.icann.org
 Cc: Paul Wouters p...@xelerance.com, Bind Users Mailing List 
 bind-users@lists.isc.org, Timothe Litt l...@acm.org
 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 
 c...@cam.ac.ukhttp://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.ukhttp://us.mc529.mail.yahoo.com/mc/compose?to=c...@cam.ac.uk


 ___
 bind-users mailing list
 bind-users@lists.isc.orghttp://us.mc529.mail.yahoo.com/mc/compose?to=bind-us...@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


Resolving .gov w/dnssec

2010-04-22 Thread Timothe Litt
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.

state.gov does not get this error.  Note that it uses different nameservers
than uspto.

Resolving uspto.gov using comcast's resolver (75.75.75.75) does not get this
error.

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

Here are details (using the -ESV server).

Subset named.conf:

options {
listen-on { 192.168.148.4; 192.168.148.5; };
dnssec-enable yes;
  dnssec-validation yes;
  dnssec-lookaside . trust-anchor dlv.isc.org.;
  sig-validity-interval 8 2;
}
trusted-keys {
dlv.isc.org. 257 3 5
BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt TDN0YUuWrBNh;
};

Examples:


;  DiG 9.6-ESV  @192.168.148.4 state.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 35438
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0

;; QUESTION SECTION:
;state.gov. IN  A

;; ANSWER SECTION:
state.gov.  60  IN  A   72.166.186.160

;; AUTHORITY SECTION:
state.gov.  299 IN  NS  Ns1.terrenap.net.
state.gov.  299 IN  NS  Ns3.yipes.com.
state.gov.  299 IN  NS  Ns1.yipes.com.
state.gov.  299 IN  NS  Ns2.terrenap.net.
state.gov.  299 IN  NS  Ns2.yipes.com.

;; Query time: 441 msec
;; SERVER: 192.168.148.4#53(192.168.148.4)
;; WHEN: Thu Apr 22 07:37:46 2010
;; MSG SIZE  rcvd: 154

 dig @192.168.148.4 uspto.gov

;  DiG 9.6-ESV  @192.168.148.4 uspto.gov
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

 dig @192.168.148.4 +cdflag uspto.gov

;  DiG 9.6-ESV  @192.168.148.4 +cdflag uspto.gov
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 18584
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;uspto.gov. IN  A

;; ANSWER SECTION:
uspto.gov.  7200IN  A   151.207.247.130
uspto.gov.  7200IN  A   151.207.243.129

;; AUTHORITY SECTION:
uspto.gov.  78721   IN  NS  DNS2.uspto.gov.
uspto.gov.  78721   IN  NS  DNS1.uspto.gov.

;; Query time: 27 msec
;; SERVER: 192.168.148.4#53(192.168.148.4)
;; WHEN: Thu Apr 22 07:40:27 2010
;; MSG SIZE  rcvd: 97

dig +dnssec @192.168.148.4 dlv.isc.org

;  DiG 9.6-ESV  +dnssec @192.168.148.4 dlv.isc.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 43521
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dlv.isc.org.   IN  A

;; ANSWER SECTION:
dlv.isc.org.300 IN  A   149.20.16.8
dlv.isc.org.300 IN  RRSIG   A 5 3 300 20100522083002
20100422083002 64263 dlv.isc.org.
MG9aDOgjqEMA3QcUQDDUac/YcHki0bPnXre6iyehi2jY3swg/zp3IOb4
Wf5cFQfIxQIf2n9EAw7tkBxhFZ2alDMEkotEVTPF13SYc+PP8EhV7vEF
OZc1snFat7R0YeeATpkZD5xaeYzkLZS1coiSJGiqCYrNoWDKi/DoP9TB RFo=

;; AUTHORITY SECTION:
dlv.isc.org.2696IN  NS  dlv.ord.sns-pb.isc.org.
dlv.isc.org.2696IN  NS  dlv.ams.sns-pb.isc.org.
dlv.isc.org.2696IN  NS  ns2.isc.ultradns.net.
dlv.isc.org.2696IN  NS  dlv.sfba.sns-pb.isc.org.
dlv.isc.org.2696IN  NS  ns1.isc.ultradns.net.
dlv.isc.org.2696IN  NS  ns.isc.afilias-nst.info.
dlv.isc.org.2696IN  RRSIG   NS 5 3 3600 20100522083002
20100422083002 64263 dlv.isc.org.
Ae2XBq3ibOKvx36NfB5ghOnHOH5XG1XFzVC/4ZCyu7lwxxh1RlVrMLcU
UHboYzBqdc/4bQ7SlELBSi34IN8BPm0tDpNmGmafXHj8ZqdojJxyLc07
Q9Hx15IJRkOcqKSmLAZq5VzfJDV9VeaPp6Xt4uVVpV1huzNwdzongjkB F0s=

;; Query time: 16 msec
;; SERVER: 192.168.148.4#53(192.168.148.4)
;; WHEN: Thu Apr 22 07:52:49 2010
;; MSG SIZE  rcvd: 561

Dnssec logging for uspto.gov lookup:

22-Apr-2010 08:00:09.497 dnssec: debug 3: validating @0x8550e58: uspto.gov
A: starting
22-Apr-2010 08:00:09.497 dnssec: debug 3: validating @0x8550e58: uspto.gov
A: looking for DLV
22-Apr-2010 08:00:09.497 dnssec: debug 3: validating @0x8550e58: uspto.gov
A: plain DNSSEC returns unsecure (.): looking for DLV
22-Apr-2010 08:00:09.497 dnssec: debug 3: validating @0x8550e58: uspto.gov
A: looking for DLV 

Re: Resolving .gov w/dnssec

2010-04-22 Thread Paul Wouters

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. The logs show:

Apr 21 18:03:54 nssec unbound: [19439:1] info: validation failure DNS2.uspto.gov. 
A IN
Apr 21 18:03:54 nssec unbound: [19439:1] info: validation failure uspto.gov. NS 
IN
Apr 21 18:03:54 nssec unbound: [19439:1] info: validation failure DNS1.uspto.gov. 
A IN
Apr 22 09:45:32 nssec unbound: [19439:0] info: validation failure uspto.gov. A 
IN
Apr 22 09:45:34 nssec unbound: [19439:1] info: validation failure DNS2.uspto.gov. 
A IN
Apr 22 09:45:34 nssec unbound: [19439:1] info: validation failure uspto.gov. A 
IN
Apr 22 09:45:34 nssec unbound: [19439:1] info: validation failure uspto.gov. NS 
IN
Apr 22 09:45:34 nssec unbound: [19439:1] info: validation failure DNS1.uspto.gov. 
A IN
Apr 22 09:46:36 nssec unbound: [19439:1] info: validation failure www.uspto.gov. 
A IN
Apr 22 09:50:38 nssec unbound: [19439:1] info: validation failure www.uspto.gov. 
A IN
Apr 22 09:52:35 nssec unbound: [19439:1] info: validation failure uspto.gov. A 
IN
Apr 22 09:57:53 nssec unbound: [19439:1] info: validation failure uspto.gov. 
DNSKEY IN

As far as I can tell (including a quick check with dnscheck --test=dnssec,
everything works out, but apparently some data in the zone does not
validate, at last not with the records cached at the time. I do have a
copy of the unbound cache if someone wants to do a post-mortem of validating
all the cached records crypto

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


Re: Resolving .gov w/dnssec

2010-04-22 Thread Torsten
Am Thu, 22 Apr 2010 10:03:43 -0400 (EDT)
schrieb Paul Wouters p...@xelerance.com:

 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. The
 logs show:
 

Maybe something went wrong in the key-rollover process. Queries
for DS, DNSKEY and NSEC get a reply with the ad flag set. All other
records fail.


Ciao
Toto

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


Re: Resolving .gov w/dnssec

2010-04-22 Thread Chris Thompson

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


Re: Resolving .gov w/dnssec

2010-04-22 Thread Joe Baptista
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 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

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

RE: Resolving .gov w/dnssec

2010-04-22 Thread Timothe Litt
So, others are also seeing this, and it's not unique to bind or my corner of
the internet.  Thanks.

It seems to have been going on for weeks, so it isn't going to fix itself.

Who do I report this to so that it gets resolved?  

FWIW, I tried +vc - from here, it doesn't help.  Also, one sometimes gets
SERVFAIL - and once in a while, it actually resolves!

As for the make work project and less stability comment -- it seems
likely to me that if DNS packets are being mishandled, others are too --
just not as visibly.  So DNSSEC may well be an over-due network diagnostic;
fixing these sorts of problems could equally well reduce retries, delays and
other mishandled fragments for other protocols. I'm not ready to blame the
indicator for the underlying problem.  At least until we get to a
DNSSEC-unique root cause.

-
This communication may not represent my employer's views,
if any, on the matters discussed.
-Original Message-
From: Chris Thompson [mailto:c...@hermes.cam.ac.uk] On Behalf Of Chris
Thompson
Sent: Thursday, April 22, 2010 10:52
To: Paul Wouters
Cc: Timothe Litt; Bind Users Mailing List
Subject: Re: Resolving .gov w/dnssec

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


Re: Resolving .gov w/dnssec

2010-04-22 Thread Paul Wouters

On Thu, 22 Apr 2010, Chris Thompson wrote:

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.


But wouldn't it fall back to TCP then? Also with dig +cd I got an
instant answer, and the (old) cache dump contains the dnskey.

So I don't think that's the full story.

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


Re: Resolving .gov w/dnssec

2010-04-22 Thread Nate Itkin
On Thu, Apr 22, 2010 at 08:06:03AM -0400, Timothe Litt wrote:
 I'm having trouble resolving uspto.gov with bind 9.6.1-P3 and 9.6-ESV
 configured as valdidating resolvers.
 [snip]
 Is anyone else seeing this?  Ideas on how to troubleshoot?

Not specifically, but I log a lot of errors resolving in usps.gov. USPS
clearly has configuration issues.  A representative sample from my logs:

19-Apr-2010 11:04:23.072 lame-servers: no valid RRSIG resolving 
'EGQ1REIRR8NVE4U6I97RO3PC2CRUU1A5.usps.gov/DS/IN': 56.0.82.25#53
19-Apr-2010 11:04:24.099 lame-servers: no valid RRSIG resolving 
'samtcatwe0d3.usps.gov/DS/IN': 56.0.82.25#53
19-Apr-2010 11:04:24.890 lame-servers: no valid DS resolving 
'samtcatwe0d3.usps.gov//IN': 56.0.100.25#53
19-Apr-2010 11:04:27.975 lame-servers: no valid NSEC resolving 
'samtcatwe0d3.usps.gov/MX/IN': 56.0.100.25#53

Hopefully someone on the list knows a clueful USPS administrator they can
contact. 

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


Re: Resolving .gov w/dnssec

2010-04-22 Thread Casey Deccio
On Thu, Apr 22, 2010 at 11:17 AM, Nate Itkin bind-us...@konadogs.netwrote:


 Not specifically, but I log a lot of errors resolving in usps.gov. USPS
 clearly has configuration issues.  A representative sample from my logs:

 19-Apr-2010 11:04:23.072 lame-servers: no valid RRSIG resolving '
 EGQ1REIRR8NVE4U6I97RO3PC2CRUU1A5.usps.gov/DS/IN': 56.0.82.25#53
 19-Apr-2010 11:04:24.099 lame-servers: no valid RRSIG resolving '
 samtcatwe0d3.usps.gov/DS/IN': 56.0.82.25#53
 19-Apr-2010 11:04:24.890 lame-servers: no valid DS resolving '
 samtcatwe0d3.usps.gov//IN': 56.0.100.25#53
 19-Apr-2010 11:04:27.975 lame-servers: no valid NSEC resolving '
 samtcatwe0d3.usps.gov/MX/IN': 56.0.100.25#53


The usps.gov servers are not returning all the appropriate RRSIGs to cover
the NSEC3 RRs returned for denial of existence.  This is consistent with all
their servers.

$ dig @dns100.usps.com +dnssec usps.gov 

;  DiG 9.6.1-P3  @dns100.usps.com +dnssec usps.gov cname
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 40506
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;usps.gov.  IN  CNAME

;; AUTHORITY SECTION:
usps.gov.   1800IN  SOA dns141.usps.com.
domainadmin.imail.usps.gov. 285717992 3600 1800 1209600 1800
usps.gov.   1800IN  RRSIG   SOA 7 2 3600 20100502025431
20100422015431 43133 usps.gov.
grQ5+JGDwezIsv2g5jAEXARLnW/leCieA/13Uxt8zZVZmUlozObsxHEo
r3NuB1cF9MOg1NppkJbwKswC4AFg1lT9RZ3hAVEvFL4clLzgFYUlEmpN
3hdqJ+1ZO05zramz9loaP1TWcJPSUtLosFQaD4OuJHimxCxmMk0Qnke5 EAs=
EGQ1REIRR8NVE4U6I97RO3PC2CRUU1A5.usps.gov. 1800 IN NSEC3 1 0 100 -
EHU10MMN93MNBII1G8R5MUSB0EKKKFPK NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM
TYPE65534

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

Re: Resolving .gov w/dnssec

2010-04-22 Thread Michael Sinatra

On 4/22/10 8:55 AM, Timothe Litt wrote:

So, others are also seeing this, and it's not unique to bind or my corner of
the internet.  Thanks.

It seems to have been going on for weeks, so it isn't going to fix itself.

Who do I report this to so that it gets resolved?


I have had good luck reporting this issues to the contact in the SOA:

;; ANSWER SECTION:
uspto.gov.  7200IN  SOA dns1.uspto.gov. nmb.uspto.gov. 
2010042002 10800

and I also cc Donna Samblanet who is the whois contact for GOV.  (Try 
'whois -h whois.iana.org =GOV' at your favorite unix prompt for her 
contact info.)



FWIW, I tried +vc - from here, it doesn't help.  Also, one sometimes gets
SERVFAIL - and once in a while, it actually resolves!


That may explain why it's broken for you and not for me.  My BIND 
servers (a mix of 9.7.0-P1 and 9.6.1-P3) all resolve uspto.gov 
correctly, with the AD bit set.  That's because they lower the EDNS0 
buffer if they don't get a response right away, thereby triggering a 
fallback to tcp.  Are you blocking (or is your network blocking) tcp/53 
somewhere?



As for the make work project and less stability comment -- it seems
likely to me that if DNS packets are being mishandled, others are too --
just not as visibly.  So DNSSEC may well be an over-due network diagnostic;
fixing these sorts of problems could equally well reduce retries, delays and
other mishandled fragments for other protocols. I'm not ready to blame the
indicator for the underlying problem.  At least until we get to a
DNSSEC-unique root cause.


You're correct that this isn't a DNSSEC problem.  It's arguably not even 
a DNS problem, since UDP fragments are used by other protocols.


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